Featured

Dynamics 365 for Finance and Operations Inventory Cost Model, Part 4: Landed Cost

This is the fourth instalment in my series of articles explaining the inventory cost model in Dynamics 365 for Finance and Operations (D365FO). The series is expected to include the following parts:

In the previous posts, we looked at the core concepts underpinning the inventory cost model in D365FO and how some of the key areas should be configured. In this post we will look more into how you work with landed cost.

 

I am not sure if there is a formal definition of what landed cost is, but for the purpose of this article landed cost is defined as:

Total cost of an inbound shipment of goods including product cost, freight, insurance and duties.

The concept of charges

In D365FO, landed costs are recorded and managed through so-called Charges. A charge can be any type of landed cost and can be set up for products and suppliers. A charge is a relatively simple concept based on the following business logic:

  • A Charge can be applied to a purchase order header or lines manually or automatically.
  • A charge cannot be split across multiple purchase orders.
  • A purchase order header charge can be allocated across the purchase order lines (manually).
  • Purchase order line charges can be included in the product cost and taken into the inventory.
  • A charge can only be applied to the supplier on the purchase order – not a 3PL supplier.
  • Charges on a purchase order are perceived to be estimated – realised charges are connected to the invoice.

Configuring charges

Before we can use Charges in D365FO, they need to be configured. Since we are dealing with inbound charges, the configuration takes place in the Procurement and sourcing module under Setup / Charges.

Firstly, we must configure the necessary charge codes as shown in the following example.

Inventory 1.PNG

The key decision to make here is how to post the charge to the general ledger. In this case, FREIGHT, the cost (debit) is posted to a nominal ledger account (600120) and the debt (credit) is included is the amount owed to the supplier and therefore the accounts payable account set up for the supplier.

In the next example, FEE, the debit configuration is pointing to Item. This means that the charge will go to the inventory account for the item on the purchase order line and be included in the inventory value.

Inventory 2.PNG

Obviously, charge codes with debit posting set to Item are only relevant for purchase order line charges.

Once the charge codes have been defined, they can be used manually on a purchase order. However, most companies would like to have default charges applied automatically. This is set up as Automatic charges.

Firstly, I have set up a handling fee of $5.00 for vendor 1001 as shown in the following example. This is set up as a Header charge.

Inventory 3.PNG

This means. that all purchase orders for vendor 1001 will have a handling charge applied to the purchase order header automatically.

Next, I have set up two line item charges for freight and fee respectively. The freight charge is multiplied by the quantity on the purchase order line. The fee charge is a fixed amount for each purchase order line.

Inventory 4.PNG

The charges are automatically applied to all purchase order lines for vendor 1001, item 1000.

I could also have set up automatic charges for a group of vendors or a group of items. These groups are maintained in special charges groups.

Use of charges in the purchasing process

When I create a new purchase order for vendor 1001, the handling charge is automatically applied as shown in the following screenshot.

Inventory 5.PNG

If required, I can add, change or delete charges in the purchase order header. Charges in the purchase order header are maintained under Maintain charges.

The purchase order header charge is a general charge that will not be included in the inventory value. The charge can be allocated to the purchase order lines instead by using the Allocate charges menu point as shown below.

Inventory 6.PNG

Now, when I create a purchase order line for item 1000, the freight and fee charges are automatically applied as shown here.

Inventory 7.PNG

Since the fee charge is fixed, it does not change with the order quantity whereas the freight charge does.

Once the purchase order has been confirmed to the supplier, changes to charges cannot be applied until the invoicing stage.

Invoicing matching

At the invoicing stage, the user cannot remove the estimated charges on the purchase order. The purchase order charges are automatically connected to the invoice charges, but the user can remove the connection and apply new corrected charges. This way, the user can match the invoicing but at the same allow comparison between estimated charges and actual charges for that purchase order.

Charges postings

The following screenshot shows the inventory transaction details for the purchase order line after the supplier invoice has been applied.

Inventory 8.PNG

As you can see, the purchase order line amount of $1,798.00 has been increased to $1,798.50 because of the $0.50 fixed fee charge. This charge has been included in the inventory value because the charge code was set up to post the debit side to the item.

If we look at the financial voucher for the purchase order as a whole, we can see that the $2.00 freight charge has been taken to the “Freight/transportation in” account and the $5.00 handling charge has gone to “Other miscellaneous expenses” account. Lastly, it is worth noting that the accumulated charges have been added to the accounts payable account as well.

Summary

The above example pretty much sums up what can be achieved with charges in D365FO. If your requirements involve distributing freight charges across multiple purchase orders, the Transportation management module may be applicable, but it is beyond the scope of this article.

As mentioned, the system keeps both the estimated and the realised charges, but I have yet to find a report that shows a comparison or any statistics.

 

 

Making a Field Mandatory in Dynamics 365 for Finance and Operations without Customization

In previous versions of Dynamics 365 for Finance and Operations (D365F&O), making a field mandatory required a (small) customisation. With version 10.0.0.12 this is no longer the case. Now it is possible to make fields mandatory using personalisation.

In the following example, I would like the Organization number field to be mandatory. To do this, I simply right-click on the field and select Personalisation from the menu. As the following screenshot shows, I can now tick the Required option.

As shown below, the field is now mandatory (red and marked with an asterisks) when editing the record.

Obviously, it is unlikely that an organisation would allow all users to perform this type of personalisation. Since the mandatory (required) field personalisation is saved with the view (in this example “Contoso Customers”, it is possible for an administrator to configure corporate views and distribute them as shown below.

In the above example I am distributing the view to all users in the “Accounts Receivable Clerk” role.

Please note: Instead of right-clicking on the field, the required field personalisation option is also available from the Personalize this page function in the ribbon.

This feature is still in preview, but you can follow updates here.

Adding a Power App to a Tab Page in Dynamics 365 for Finance and Operations

With Platform Update 32 it has become possible to embed a Power App (or web page) directly in the form in addition to the ability to adding it to the ribbon.

In this example I have created a simple Power App that shows customer contacts and allows me to call them using Microsoft Teams. The Power App takes a customer account number as a parameter and filters the contacts list accordingly.

I would like to add this Power App to the customer details forms.

The Power App is added through personalisation. To kick-off the process I start the personalisation dialogue from my Saved View (My View) as shown above.

Subsequently, I select Add an app from the personalisation menu.

This brings up a gallery where I can choose between adding a Power App or a web site as shown in the following screenshoot.

After selecting Power Apps in the gallery, I must provide details about the app I am adding.

The Name field contains the name of the new tab page containing the app. The App ID is the GUID identifying the Power App. In the Input context for the app field I select the “Account – CustTable_AccountNum” value to pass the customer number to the app. Since the app should be available for all legal entities, I do not fill in the Legal entity access section.

Note: Since this is a personalisation, so remember to save the view before reloading the form. Otherwise, the personalisation will disappear.

As the following screenshot shows, the Power App has now been added to the form.

This is a very simple and effective way of adding contextual Power Apps to the standard user experience without customisation.

Please note that this feature is still in preview and future development will follow. For more information, please see this article.

Dynamics 365 Supply Chain Management, Asset Management (Part 2)

In the first part of this series we took a look at how to structure master data in Asset Management. In this part we will walk through a break-fix end-to-end scenario. For those unfamiliar with asset management terminology, break-fix means that an asset breaks down and needs immediate fixing.

Break_Fix Background

The scenario we will go through is based on the above background story.

To request maintenance on an asset, the user must create a maintenance request. This is normally done in the Dynamics 365 Finance and Operations (D365F&O) browser client, but in this example we will use a virtual agent bot instead. Using Power Virtual Agents, Power Automate and Odata I have created a bot that allows casual users to create maintenance requests.

Reset Bot

In the above screenshot, the user has reset the bot by using the phrase “Start over”.

Create Request

To start the process of creating a new maintenance request, the user enters the trigger phrase “Create request”.

Select Request Type

The user can now select between the three maintenance types available in the system. Once the user has selected a maintenance type, he or she is asked for a description of the problem.

Enter Asset ID

The user must then enter the identification number for the asset.

Confirm Asset

The system looks up the identification number in D365F&O and returns the name of the asset for confirmation by the user.

Additional Notes

Once the user has confirmed the asset, the bot offers the user the option to add a more detailed description of the problem.

Additional Notes

In this case, the user provides further detailing of the problem.

Create Request

The bot now creates a new maintenance request using Power Automate and returns with the request number to the user. The bot dialogue is now finished and the request has been created in the system as shown below.

Bot 9_LI

If the user had used the browser client instead, the dialogue would have looked like this:

Asset 1_LI

In our scenario, we will continue with the maintenance MR-000020 maintenance request. Once the request has been submitted it becomes available in the “Maintenance request without work order” view in the Maintenance request management workspace as shown below.

Asset 2_LI

From here, the maintenance manager can create a work order directly.

The work order is the source document that allows a field service technician to carry out work and record consumption.

Asset 5_LI

Based on information provided on the maintenance request from, the work order has now been created. The work order is linked directly to the maintenance request. When the work order is created, it is automatically given the lifecycle state “New”. This is governed by the company’s configuration of lifecycle states. Until it reaches life cycle state “Scheduled”, the work order is not available in the mobile app.

Through the set up, a “Repair” job is automatically created on the work order, when the work order type “Corrective” is selected. As shown below, the combination of job type and asset also automatically generates a check list for the field service technician.

Asset 6_LI

In a future post we will explore scheduling of maintenance jobs so for now, let us assume that the job has been assigned to the preferred worker for the asset, Amy. In the following I will walk through how Amy carries out the maintenance task using the mobile app.

Mobile Job 2

Divider 1

Mobile Job 1

Divider 1

Mobile Job 3

Divider 1

Mobile Job 4

Divider 1

Mobile Job 5

Summary

In this brief example we have taken a quick look at how a broken asset can be fixed. The process is started through a maintenance request. The maintenance request becomes a work order and through configuration, maintenance jobs are added to the work order. Each job can be associated with a check list. The check list is used in the mobile app to guide the field service technician. Also, in the mobile client, the field service technician can record time, materials consumption and expenses.

In the next part of this series, we will take a closer look at how to set up preventive maintenance and how maintenance jobs are scheduled.

 

 

 

 

 

 

 

 

 

Dynamics 365 Supply Chain Management, Asset Management (Part 1)

In this first part of the series on Asset Management (AM) in Dynamics 365 Supply Chain Management (D365SCM), we will take a look at how master data is structured and configured, but before we got into this, I would like to briefly discuss the purpose of the module and its capabilities.

Purpose of Asset Management

What is the purpose of AM? Companies generally invest large sums in assets such as buildings, plant machinery and IT equipment. To keep these assets in working order and to retain maximum value, the asset must be maintained.

This is simply the purpose of Asset Management: maintaining company assets.

Some companies also maintain other companies’ assets, but this is not the purpose of AM in D365SCM – for this you need Dynamics 365 Field Service.

AM is often divided into three distinct disciplines:

  1. Break-Fix (something has gone awry, fix it).
  2. Preventive (based on usage or time, an asset is maintained before it breaks).
  3. Predictive (based on data points we are able to predict when an asset will break).

At this stage, Asset Management supports break-fix and preventive maintenance.

Capabilities

The following figure shows an overview of the capabilities available in the AM module.

Capabilities

Here is a brief description of each capability:

ASSET MANAGEMENT: The module is centered around the concept of a physical asset. An asset can be hierarchical and is always installed in a so-called functional location. We will explore asset management in detail later in this blog post.

REQUEST MANAGEMENT: If an asset fails or needs general maintenance, users can raise a maintenance request. The request contains information about the fault and is routed to an Asset Manager, who validates the request. If relevant, the Asset Manager creates a work order to remedy the problem and puts it into the maintenance schedule.

WORK ORDER MANAGEMENT: The work order is the central component in carrying out maintenance work whether the maintenance is preventive or break-fix. Based on pre-configured scheduling parameters, the work order is routed to a Field Service Technician. A work order can contain multiple jobs and can be worked on from a mobile device.

SCHEDULING: The ability to schedule work order jobs based on predefined factors such as priority, worker availability, worker skills, service level etc.

SPARE PARTS TRACKING: When performing maintenance on an asset, the Field Service Technician can record parts consumption. This can be tracked and used to update the asset bill of materials.

CONSUMPTION: As maintenance work is performed, the Field Service Technician or Asset Clerk can record time, parts and other expenses against the work order.

KPIs: The system automatically calculates a range of KPIs including:

  • Total Up-time.
  • Total Downtime.
  • Total Repair Time.
  • Availability %.
  • Number of Faults.
  • Meantime Between Faults (MTBF).

COST CONTROL: All costs related to maintenance can be budgeted and recorded. The AM module has a Cost Control real-time inquiry that allows asset controllers to perform multi-dimensional analysis of budgets and costs.

FAULT MANAGEMENT: Through a matrix approach, the system can be configured to suggest a remedy to a fault. Fault details are recorded for further analysis.

PREVENTIVE MAINTENANCE: In addition to break-fix maintenance, the system supports maintenance plans and maintenance rounds. Both types allow automated creation of work orders based on pre-set maintenance schedules. We will look at plans and round in more details in a later part of this series.

Module Integration

Since AM is part of Dynamics 365 for Finance and Operations (D365F&O) it seamlessly integrates with other modules. We will look at this in more detail later in the series, but here is a brief list of the modules integrated with AM:

  • Project Management and Accounting.
  • Inventory Management.
  • Procurement and Sourcing.
  • Fixed Assets.

Master Data Structure

As mentioned earlier, in this part of the series, we will focus mainly on structure and master data. These topics will be explored in the following subsections.

Functional Locations

Imagine a factory. In that factory you have multiple production lines and each production lines consists of a number of work cells. This hierarchy is illustrated in the following figure.

Functional Locations

Each part of this hierarchy is a functional location.

An asset is installed in a functional location.

This is important because this allows us to:

  • Perform maintenance on (multiple) assets in a specific location.
  • Assign workers to specific locations.
  • Default information on new assets and work orders based on functional location.

In addition, functional locations can be used to filter reports and analyses.

Assets

Obviously, the core component of AM is the asset. An asset is a system representation of a specific physical asset and contains data to describe the asset including:

  • Description.
  • Manufacturer.
  • Model.
  • Serial number.
  • Attributes (more on those later).
  • Warranty information.
  • Condition.
  • Financial dimensions.

Assets can be linked together in a hierarchical structure. The following screenshot shows the asset hierarchy for the “EX-101 Extruder line 1”:

Asset View

As you can see, the “EX-101” asset consists of five sub assets.

You can read more on the structure of functional locations and assets here.

Life Cycle State

A common (and very important) concept in AM is the life cycle state. Both functional locations and assets have a life cycle state attribute. The life cycle state describes where the functional location or asset is in its life cycle. It also determines what can be done to the object.

Asset Lifecycle State

The above screenshot shows the configuration for asset life cycle state. As the example shows, the “New” state does not have the Active field ticked. This means that assets with life cycle state = “New” are not active and maintenance can not be carried out on them.

Life cycle states are governed in a life cycle model. The following figure shows an example of a life cycle model for assets.

Asset Lifecycle Model

The life cycle model determines the states an asset can go through and the sequence.

Similar life cycle models and states can be configured for:

  • Functional locations.
  • Work orders.
  • Maintenance requests.

Summary

So to recap; assets are the key master data component in the asset module. Maintenance is carried out on the asset and assets are installed in functional locations. Both functional locations and assets can be structured in hierarchies.

Both functional locations and assets are governed by life cycle models consisting of a configurable set of life cycle states.

Mandatory Configuration

In addition to the life cycle model and life cycle states, some additional basic configuration is required for functional locations and assets.

Functional Location Types

When creating a new functional location, the user must select the functional location type. The functional location type controls a number of things including:

  • Can multiple assets be installed in the location?
  • What types of asset are allowed in the location.

Asset Types

Similarly, the user must select an asset type when creating a new asset type. Asset types are significantly more complex than functional location types, so please refer to the documentation for more details.

Optional Configuration

In addition to the mandatory configuration, some optional configuration is useful.

Counters

An asset can be associated with one or more counters. The counters are used to schedule preventive maintenance. The asset types determines which counters are allowed for an asset. In a future part of the series, we look at how counters are used in preventive maintenance and how counters can be updated automatically or manually.

Attribute Types

Since assets come in many varieties describing them in a simple master data record is not possible. Instead, an asset can be described in detail through attributes. An attribute on an asset is based on an attribute type. The following screenshot shows examples of attribute types.

Attribute Types

Please note that attribute types can have different data types.

The asset type determines which attributes types are available on an asset.

In a future part of this series we will look at how attributes can be used when installing an asset in a functional location.

Further Reading

The official Microsoft documentation for AM is available here.

Next Part in This Series

In the next part of this series, we will take a look at a break-fix end-to-end scenario using a mobile device.

 

 

Asset Management in Dynamics 365 Supply Chain Management

Asset Management is a fairly recent addition to Dynamics 365 Supply Chain Management (D365SCM). In a coming series, I will take a closer look at the module. However, since the module is relatively large, I have decided to break the series into a number of themed posts:

  • Structure and configuration.
  • Asset Management Master Data.
  • Repair Scenario using a Mobile Device.
  • Working with Asset BOMs.
  • Preventive Maintenance.
  • Extending Asset Management through the Power Platform.
  • Advanced Asset Management.

If you find the above interesting, stay tuned for the coming series…

If you want to take a closer look at the Microsoft documentation for Asset Management, you can find it here.

Dynamics 365 for Finance and Operations as a Windows 10 app

This is a quick tip for those of you, who have not seen it before. With the new Microsoft Edge browser (and Google Chrome) it is possible to install a web page as a Windows 10 app and make it appear in the Start menu. More important, you can pin the app to the process line so it is easily accessible.

This is what Dynamics 365 for Finance and Operations (D365F&O) looks like as a Windows 10 app:

D365F&O Windows 10 app

To add D365F&O as an app, open the application URL in the browser. In the browser click on the … in the right hand corner. From the menu select Apps and then Install Dynamics 365 for Finance and Operations. Once done, D365F&O is available in the Start menu.

Another tip is: you can do the same for the Full Details screen for your cloud hosted environment in LCS. This way, you can quickly access your favourite environment directly from the process line.

I hope you find the above useful – I certainly use it all the time.

Creating a Customer Service Bot for Dynamics 365 for Finance and Operations using Power Virtual Agents (Part 2)

In the first part of this series, I gave a general introduction to how you can combine Power Virtual Agent bots (PVAB) with Dynamics 365 for Finance and Operations (D365F&O).

In this second installment, I will take a closer look at how you connect your bot to functionality in D365F&O. In the example, I will use the bot to create a sales order based on customer input.

Look Up Customer and Create Order

As you may recall from the previous post, firstly I ask the user for a customer number as shown below.

Bot 2

The user responds with “us-017”.

This is what it looks like when I configure the bot in the PVAB canvas:

Bot 15

The user response is stored in a variable called CustomerNumber.

The following screenshot shows the Sales Bot Find Customer Power Automate flow that is called from the bot action.

Bot 15

As you can see, the flow starts with receiving data from the PVAB as input (just like a PowerApps flows) and ends by returning values back to the PVAB.

In the second action in the flow (Set Initial Response Code), I set a response code. This enables the PVAB to route the user down a different path, if the customer record is not found in D365F&O.

Further down the flow, a Dynamics 365 for Finance and Operations action is used to look up the customer record in D365F&O.

Please note, the composite key used in the Object id field is used to retrieve a single record directly.

Once the record has been found, the customer name is set.

Bot 17

If the customer name is not blank, the response code is set to “200” to indicate that the customer has been found. Subsequently, the Create record action is used to create a new sales order header in D365F&O and the sales order number is stored in the Sales ID variable.

All that remains is to pass the information back to the PVAB:

Bot 18

In the PVAB we can now lead the user down different routes depending on the response code as shown below.

Bot 19

Find Product

Next step is to ask the user for the product they would like to add to the sales order:

Bot 20

The response is used to call the Sales Bot Find Product Power Automate flow, which finds the product using firstly product number and secondly search name.

The flow is similar to the one above, but there is a difference as shown below.

Bot 21

Firstly, the flow tries to look up the product using the product number. Following that, the ResponseProduct variable is set to either “Not Found” or “Found”. If the variable is set to “Found” it will not try to look up the product using search name. What happens after the Find Product via ID action has executed is controlled in the Configure run after setting in the subsequent actions. This is the configuration for the Set Product Not Found action:

Bot 22

Create Order Line

The PVAB continues with confirming that the correct product is found and asks what quantity the user wants.

Bot 23

Lastly, a flow called Sales Bot Create Line is used to insert the sales order line in D365F&O. The flow is shown below.

Bot 24

As you have seen in the above, Power Virtual Agent and Power Automate are closely integrated. Power Automate is used to take action on data fed into the chat bot and return relevant responses.

How Will You Keep Your Dynamics 365 for Finance and Operations Fresh?

So, you have gone live with Dynamics 365 for Finance and Operations (D365F&O) so all is well for the next 10 years? This is the era of evergreen solutions, so why worry? 

Here’s why: Evergreen is a journey – not a destination…

Please let me explain.

Managing Change

Firstly, your company will change. If not, it will go out of business at some stage. What is your process for governing and implementing those changes in your solution? If you are not able to change the solution with what the business needs, it will quickly become irrelevant and legacy. D365F&O has a lot of tools to help you support these changes including:

  • Flexible accounting structures.
  • Configurable workflows.
  • Date-controlled organisations.
  • Personalisation (and distribution) of the user interface for specific tasks.
  • Role based work spaces.
  • Extension and customisation through code or the Power Platform.

Almost all elements of the application configuration can be changed, but do you have a process in place for managing and executing these changes? Changes to application configuration may affect existing business processes, so a change management process is clearly needed.

Introducing New Technologies

Surely, a key advantage of an evergreen solution (in this case D365F&O) is the continuous innovation Microsoft is making in new technologies and tools such as the Power Platform, Artificial Intelligence (AI) and integration to Azure Services. How are you planning to assess and leverage these innovations? Not all new innovations may be relevant in your context, but assessing and selecting the right ones will be crucial to your company’s future competitiveness.

You can stay up-to-date with changes introduced in D365F&O here.

Application Life Cycle Management

Going live is just the first step in the life cycle of your solution. Going live with an ERP solution requires tremendous effort, but effort is still required to keep the solution fresh going forward.

Customisation

The business will continue to evolve and (probably) request new customisations. Also, standard functionality evolves and may render an existing customisation redundant. During the implementation phase, ideally you should have built a governance procedure for requesting, approving and building customisations. Now, after go-live, you should be able to continue this process albeit in a scaled-down version.

Hopefully, application configuration has been locked-in and protected through application security (if not, maybe now is the time to review application security). Do you also consider a change to application configuration as a “customisation” and do you have strong governance around this?

Tuning

Microsoft takes care of a lot of the core database tuning, but not all. Tuning relies on a joint responsibility model. The service operations model is described in this document. I will strongly encourage you to familiarise yourself with the details of this document to make sure you are set up to deliver on your own responsibilities.

An essential part of application tuning is to clean up unused data. This blog post does a good job of highlighting, which jobs are required to clean up the application. This link provides a description of how to clean up batch job history. D365F&O runs on SQL Server and like any other database, indexes may become fragmented. A batch job has been introduced to defragment indexes on a regular basis. You can read more about this here.

In the Data Management work space a new clean up job called Job History Clean Up has been introduced. As you can see from the below screenshot, the administrator can set a cut off for how long history is kept and how often the clean up job should run.

Evergreen 1

Performance tuning is, again, a joint responsibility. To help you understand the performance of your underlying SQL Server, tools are available in Lifecycle Service (LCS) for analysis and tuning. You can read more here.

Testing

Oh yes, testing – or more precisely: regression testing. With D365F&O comes a number of tools for testing. For testing the user interface, the Regression Suite Automation Tool (RSAT) is adequate for most purposes. I have written a couple of block posts on RSAT already:

In addition, the Acceptance Test Library is available for unit testing code.

In an evergreen world, test management is king and with up to eight platform updates per year from Microsoft you need to automate as much as possible. You can read more about continuous delivery here.

Release

So you have done your customisations. Your testing is finished and you are ready to release. But what about:

  • Release notes?
  • User training?
  • Cut over activities?

In other words, releasing a customisation usually impacts people, processes and data. Do you have the processes and resources in place to manage this change?

Application Security

During implementation a lot of resources are invested in configuring application security. Roles are put in place and users are assigned with due respect to the segregation-of-duty matrix. However, as mentioned above, the business evolves and application security should evolve with it. Does your company have processes in place for:

  • Requesting changes to a role?
  • Implementing changes to a role?
  • Provisioning a new user?
  • Terminating a user?
  • Audit user assignment?
  • Audit segregation-of-duty overrides and mitigating actions?

As you can see, application security is an important issue and requires ongoing effort.

Master Data Management

Probably, this is too big a topic for a single blog post. However, I would like to point out that having processes in place for managing master data is essential for keeping the solution fresh. Not assigning sufficient resources to this area or not having proper procedures and processes in place will erode data quality and therefore the effectiveness of the solution.

Batch Management

This area is often an overlooked area, even through implementation, and can potentially be the root cause of performance issues. A lot of processing power and database capacity is usually allocated to batch processing. Often, batch jobs tend to hold relatively long and complex locks on tables with potential lock escalation issues if certain batch job run at the same time. Therefore, careful planning and monitoring of batch jobs is essential to a healthy solution.

Recommendations

Based on more than 25 years of ERP implementation experience and the feedback I receive from customers and partners, here are my top recommendations to ensure a healthy and fresh D365F&O solution:

  • Invest in managing change: By allocating the necessary resources and having the right governance procedures in place, change can and should be managed in line with how the business evolves.
  • Leverage new innovations: Leveraging the investments Microsoft is making in new innovations such as the Power Platform and AI will help the business stay competitive.
  • Test and tune: Investing time and resources in test automation will pay for itself many times in the long term. Even a cloud solution needs tuning, so applying best practice is essential.
  • Stay safe: Don’t forget to evolve application security with business needs. This way, data stays safe and the business remains compliant.

I hope the above has provided some inspiration on how you stay fresh with D365F&O.

Comments and feedback are always appreciated…

Creating a Customer Service Bot for Dynamics 365 for Finance and Operations using Power Virtual Agents (Part 1)

Have you ever wondered how you combine the power of a chat bot with data in Dynamics 365 for Finance and Operations (D365F&O)?

Wonder no more because with Power Virtual Agents you can!

In this series of blog posts I will take a look at how it is done and present you with an example. The series will consist of a number of separate posts exploring the following topics:

  1. This post. An introduction to the Contoso Customer Service Bot and the Power Virtual Agent tool set.
  2. How to use Power Automate flows to connect to D365F&O and provide rich contextual conversations.
  3. In the last post we will take a look at how you embed the bot in Microsoft Teams.

What is a Power Virtual Agent Bot?

Basically, a Power Virtual Agent Bot (PVAB) is a chat bot that is trained to respond to predefined topics (phrases) in a pre-configured flow. The PVAB flow consists of a number of components placed in a logical structure that leads the user through a task by asking questions and responding to user input.

Bot 1

In the above example I am using the opening phrase “new order” to start the conversation with the bot. In response, the bot has been configured to ask for my customer number.

Bot 2

In response to the customer order number I entered (“us-017”), the bot uses a Power Automate flow with a D365F&O connector to look up the customer. In this case, the customer account was found and the bot responds with a new question:

“What product would you like to buy?”.

In this example, I have set up a Power Automate flow that allows the user to look up the product using either the product number or the search name.

Bot 3

When I enter the product number “c0007” the bot calls the Power Automate flow that looks up the product and responds with the product name. The user is asked whether they would like to add the product to an order.

If the answer is yes, the bot continues by asking how many pieces the customer wants:

Bot 4

Once the customer enters a quantity, the bot calls a Power Automate flow that creates a new sales order and adds 5 pieces of iPhone 11 to the order in D365F&O. It returns the sales order number so the bot can inform the customer for future reference.

The bot flow has now ended successfully.

Please note: At any stage in the flow, you can pass the user to a chat experience with a customer service agent (person) through Dynamics 365 Customer Service.

Power Virtual Agent Configuration

In the following we will take a quick look at some of the core concepts in creating a PVAB bot.

I will strongly encourage you to follow the tutorial available when you create your first bot. More documentation is available here.

Create a Bot

To create a new bot in the PVAB home, click on the

Bot 7

icon in the ribbon at the top. This brings up the following dialogue where you give the bot a name and select the environment where you would like to place the bot.

Bot 6

Defining Topics

Once you have created your bot, you need to define topics that will start a bot flow. In my bot example, I have two topics:

  1. Ordering.
  2. Address Change.

The topics give the customer the possibility to create an order (see example above) or change address.

Bot 9

In the above example, I have opened the Ordering topic. For this topic, I have defined 11 phrases that will trigger the flow. If the user enters any of these phrases in the chat window, the ordering bot flow will start.

Bot Authoring Canvas

Once you have defined the trigger phrases for a topic, you click on

Bot 10

to start defining the bot flow.

The following screenshot shows the canvas for the first part of the Ordering topic:

Bot 11

The Trigger Phrases component is mandatory and automatically created.

As mentioned, I will encourage you to use the tutorial to familiarize yourself with the various component types in the canvas. However, I would like to show you a few in my example:

Bot 12

The above shows how the bot asks a question to retrieve the customer number. The input is stored in a variable called CustomerNumber. It subsequently uses the customer number variable as input to the Sales Bot Find Customer flow (in Power Automate). The flow looks up the customer in D365F&O and responds with ResponseCode (used to tell the customer if the account was found or not), ResponseName (customer name) and ResponseId (sales order number).

The following screenshots shows the components in the Power Automate flow:

Bot 14

Summary

I hope the above has motivated you to go and create your first bot in Power Virtual Agent. In the next blog post, I will take a closer look at the interaction between the bot and D365F&O through Power Automate.

Final Note: Since a PVAB can be embedded using HTML, it can embedded directly in a D365F&O screen through the new iFrame control.