Dynamics 365 for Finance and Operations Inventory Cost Model, Part 3: Cost Management

This is the third 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 actually manage costs and how this affects various parts of the system.

How you actually manage costs, depends on your scenario. Therefore, I will initially explore a couple of basic cost management areas in the system and then follow-up with an Costing and adjustment example to highlight how to use the system.

The Cost Management Module

Before we get started, I just wanted to highlight the Cost management module in D365FO:

Cost management module.PNG

This module was not available in Dynamics AX 2012. It consolidates most of the functions, queries and reports you need to manage costs in D365FO, and in addition, it brings along two new workspaces for cost administration and cost analysis.

Inventory Dimensions

The first thing to understand in D365FO when it comes to managing costs, is how to use inventory dimensions and how they affect costing.

Tracking dimensions

The above picture shows an example of a Tracking dimension group. What is important in terms costing is the tick in the Financial inventory column. This indicates that we, in this case, are tracking cost on batch level. You can use this to calculate cost on the appropriate level for a given scenario.

For instance, if you manufacture a product on two different sites, the cost is likely to be different for each site. By calculating cost by site using the inventory dimensions, you are able to correctly track cost depending on where and how you manufacture the product. Similarly, if the overhead costs in one warehouse differs from another, you can decide if you would like to track cost by warehouse.

It goes without saying that tracking cost by batch or serial number allows for very specific and granular costing. This is often used in scenarios where you need to track the specific cost of an activity. This could be sub-contracting work or very expensive materials.

In my first post on this subject, I wrote about how D365FO uses the average cost price on outbound inventory transactions. Actually, the average is based on the inventory dimensions set up, so if you have ticked the Financial inventory column on batch number, the system will use the average cost for the specific batch in question.

The Costing Sheet

How a company calculates its cost-of-goods-sold (COGS) for manufactured products is determined by the costing sheet ( for more detailed information see Docs). Only one costing sheet can be defined per legal entity.

Costing sheet.PNG

As the above example shows, the costing sheet is a hierarchical representation of the cost model. It details how materials, resources and indirect costs are included in COGS and the hierarchical structure determines how the cost calculation is displayed in various queries.

BOM Calculations

The actual calculation of COGS for a manufactured product is done through the BOM calculation (for more details see Docs). The BOM calculation is used to roll up all costs included in the BOM, route and indirect costs from the costing sheet. The BOM calculation can be invoked from various places, but most commonly it is used to calculate standard cost prices and for calculating the estimated cost of a specific production order.

Standard Cost

In many manufacturing scenarios, standard cost is used for the manufactured product. Often, this is done out of convenience but also to be able to more easily track variances.

Standard cost variance postings.PNG

As the above picture shows, variance posting can be set up across a number of variance types including variances in lot size, substituted materials and variances in materials quantity consumed.

Before setting up standard cost prices, you must define one or more cost versions. Cost versions are basically used to track the development of standard cost prices over time and simulate standard cost price calculations without affecting the current standard cost price.

Cost versions are maintained under Cost management / Inventory accounting / Costing versions.

From within the cost version, the user is able to

  • Maintain standard cost prices for each product.
  • Maintain prices for cost categories used in manufacturing routes.
  • Maintain indirect cost calculations.

This allows the user to create different standard cost calculation formulas for different segments of the product master.

You can read more about maintaining cost versions in Docs.

It is worth noting that any cost data entered in the cost version is pending until the user activates the new data.

As mentioned in my second blog post on inventory costing, a product must be linked to an item model group that is set up for standard cost as shown in the following screen:

Item model group - standard cost.PNG

When using a product that has been set up for standard cost, the system will always use the active standard cost when consuming the product on a sales order, production order etc.

As mentioned above, if the actual cost of the product is different to the standard cost price, the system will automatically post the difference to the variance account. This can for instance happen when purchasing materials. If the purchase price on the invoice differs from the standard cost price when the invoice is approved (and posted), the system posts a purchase variance. As you can imagine, this may create quite a lot of variance transactions so you need a thorough procedure for controlling variances.

Cost Prices

So, what if you are not using standard cost? How do you maintain prices? The short answer is: that depends.

At the most basic level, you can maintain the purchase price of a material directly on the product record. However, the most flexible way to maintain purchase prices for a product is to use the trade agreements where you are able to maintain prices, discounts, lead times, quantity breaks etc. When creating a purchase order line, the system will automatically use the trade agreements to find the correct purchase price. When invoicing the purchase order line, the system will use the price on the purchase order line plus any charges added to the line as well as overheads applied through the costing sheet (see above). The concept of charges will be explored further in the next blog post.

The cost of a manufactured product that is not set up for standard cost is calculated through a BOM calculation (see above).

Closing and Adjustment

And now to the big topic when managing inventory costs in D365FO: Closing and adjustment. As discussed in previous blog posts, the cost of an inventory transaction is not fixed until it has been financially settled (unless you use standard costing, in which case, closing and adjustment is redundant).

Every time you run the Closing and adjustment job (found under Cost management / Inventory accounting / Closing and adjustment) the cost of an outbound transaction may change until the entire quantity of an outbound transaction has been financially settled against inbound quantities.

Let’s try looking at Closing and adjustment through an example. The following screen shows the on-hand inventory for the product HML-007:

HML-007 On-hand 1.PNG

As you can see, we have 100 pieces in stock. Of these 100, 50 have been posted financially (invoiced) and 50 have only been received.

Now I sell (invoice) 100 pieces to a customer on a sales order. I have now sold 100 pieces at an average cost price of $510 (total cost amount of $51,000) as the following screen shows:

HML-007 Inventory transaction sold.PNG

However, the 50 pieces I have yet to invoice were purchased at $693.60 per piece (total cost amount of $34,680) as the following screen shows:

HML-007 Inventory transaction purchased.PNG

Interestingly, when you look at the on-hand inventory for HML-007 in the following screen, the system displays zero quantity in stock but an inventory cost of $9,180. This is actually, the un-allocated difference between the cost of goods purchased and the provisional COGS.

The product (HML-007) is linked to an inventory model group set to the FIFO inventory model. When I now go a perform a Closing and adjustment the system will settle inbound transactions against outbound transactions using the FIFO method. This should recalculate the COGS on the sales order inventory transaction accordingly.

Firstly, I use the Recalculation option in the ribbon. This option recalculates the inventory cost, but does not create settlements and close the inventory. This is the option to use if you would like to recalculate inventory costs daily (for accuracy) but maintain the ability to correct inventory transactions during the period. To permanently settle and close the inventory, use the Close procedure option in the ribbon.

Both recalculations and closings can be reversed.

Let’s have a look at the result of my recalculation. Firstly, let’s look at the financial transactions created:

HML-007 Closing and adjust financial voucher.PNG

As you can see, our residual of $9,180 has now been taken out of inventory and been allocated to COGS.

Similarly, the residual inventory cost value has been removed from on-hand inventory as the following screen shows:

HML-007 On-hand 3.PNG

Lastly, as the following screen shows, the COGS for the inventory sales transaction has been adjusted to include the correct cost prices for all 100 pieces.

HML-007 Inventory transaction adjusted.PNG

When I go back to the Closing and adjustment screen and run the Close inventory option, the system settles the inventory transactions and closes the inventory so I can make no further changes in the period. The resulting settlements are shown in the following screen:

HML-007 Settlements.PNG

This simple example may look easy, but with millions of transactions to settle, controlling and auditing the inventory cost system can be tricky.

Note: For product HML-007 I have used a storage dimension group set up for financial inventory by Site. If the product had been purchased across multiple warehouses, the average cost price and the FIFO recalculation would have made the calculation across all warehouse. Therefore, correction settings of this parameters can have significant impact on how the system calculates inventory costs.

You can read more about Closing and adjustment here.

Summary

In this blog post we have explored how to manage cost in D365FO. In the coming two blog posts we will be looking into how you work with landed costs and, last but not least, how to monitor and control inventory costs.

 

Advertisements
Posted in Dynamics 365 for Finance and Operations | Leave a comment

Task Guides – The Best Feature in Dynamics 365 for Finance and Operations?

Now, you may disagree with me, but I think that Task Guides are the best new(ish) feature in Dynamics 365 for Finance and Operations (D365FO). Before I tell you why, let us start with an introduction to Task Guides, if you are not familiar with them.

Task Recordings

Firstly, to use a Task Guide you need to record it using the Task Recorder in D365FO. As the following picture shows, the Task Recorder is found under Settings: in the ribbon:

Task Guides 1.PNG

Once in the Task Recorder, you have the options to create a new recording, play back a recording or edit an existing recording as the following picture shows:

Task Guides 2.PNG

Let us start by recording a new Task. In this example I would like to create a guide on how to create new customers.

Task Guides 3.PNG

Give the guide a descriptive name and press the Start button.

The task recorder is now in recording mode. You can stop the recording by clicking on the Stop button in the ribbon.

I would like to structure my Task Guide in sections, so I start my creating a sub-task:

Task Guides 4.PNG

I subsequently go to Accounts receivable / All customers and as you can see from the following screen, my actions are recorded in the sub-task:

Task Guides 5.PNG

I end sub-task 1 and create a new sub-task (2).

Now, I start creating a new customer in the user interface and again my actions are recorded. I continue to go through the steps required to create a new customer record and end by clicking the Save button. Once done, I end the sub-task (2) and stop the task recorder. I can now save my recording:

Task Guides 6.PNG

In this case, I save it to my PC.

Annotations

So far, the Task Recorder has used standard annotations to describe each step in the task guide. In the following picture, I have created a new simple customer creation guide and I would like to change the standard text for entering a value in the Customer account field. By default the text says: “In the Customer account field, type a value.”.

By clicking on the Task Guides 7.PNGicon next to the text, the system brings up the annotation dialogue:

Task Guides 8.PNG

In this case I enter my own bespoke description including a more detailed instruction in the Title field. Now when I use the Task Guide, the user gets a comprehensive instruction on how to enter the correct value in the field as shown in the following picture:

Task Guides 9.PNG

Pretty much all steps in the recording can be annotated to produce very specific instruction.

Creating Documentation

Another important feature of the Task Recorder is the ability to create a Word document directly from the recording. The following picture shows an example of a document created from the previous recording:

Task Guides 10.PNG

The document can now be augmented with more detailed instructions and links to other documents, diagram etc. In the above example I have also used the inbuilt Microsoft Translator to translate the original English instructions into German. With a few simple clicks I have created multi-lingual work instructions and training materials.

Running the Task Guide

Now that we have created a Task Guide using the Task Recorder, it is time to use it.

If you open the help dialogue from the ribbon and you have saved your recording to Lifecycle Services (LCS), the task guide will automatically appear, if you are in the All customers screen because they have been associated. In my example I have saved the recording locally, so I need to invoke it from the Task Recorder by selecting the Playback recording as guide menu point.

As the following picture shows, the task guide now takes the user through each step one-by-one providing useful instructions on the way. In the ribbon, an icon indicates whether the guide is locked or not:

Task Guides 14.PNG

When the guide is locked, the user can not “jump” out of the guide, but must follow all steps.

So, Why do I Think This is so Great?

Firstly, this is the tool the Task Recorder should have always been, but here are some of the reasons, why I think this is such as big improvement:

  • The tool allows us to provided guide data entry.
  • It is central to being able to develop user-centric training materials at a reasonable price.
  • It is linked with the Business Process Modeler in LCS providing a comprehensive solution for process documentation on activity level.
  • The tool can provide the basis for automated testing of the user interface.

Yes, the tool still has room for improvement, but in my view it is extremely useful as it stands.

Further Reading

If you want to read more about the Task Recorder and the Task Guide, please visit the Docs documentation.

 

 

 

 

Posted in Uncategorized | Leave a comment

Dynamics 365 for Finance and Operations Inventory Cost Model, Part 2: Configuration

This is the second 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:

  • Part 1: Core concepts.
  • Part 2: Configuration.
  • Part 3: Cost management.
  • Part 4: Landed cost.
  • Part 5: Cost controlling.

This article will explore the key configuration steps you need to take to set up inventory costing. Since I will not be covering all the details in this article, you can find more information here. Also, I will be focusing on configuring the necessary elements for costing, so I will not be dealing with warehouse management, quality management etc.

Item Groups and the Posting Set Up

Inventory management / Setup / Inventory / Item groups

Inventory management / Setup / Posting / Posting

The most essential part of configuring inventory costing is defining the link between the general ledger and the inventory ledger. This is done through the Posting set up screen:

Posting set up.PNG

In the Posting set up screen you define the general ledger accounts used for each inventory transaction type. You can define this link for each item, groups of items or all items.

Important note: Ideally, you set everything up on item group level.

Doing this means that you need a set of accounts in the chart of accounts for each item group. This creates quite a lot of accounts, but the benefit is that all reports that aggregate on item group level can reconcile directly to an account in the general ledger (if you are lucky).

Important note: It is extremely important that the accounts used in the chart of accounts do not allow manual postings. If you post manually to these accounts they become very difficult to reconcile to the inventory ledger.

If you need to manually adjust the financial value of inventory in the general ledger make sure to create a separate manual adjustment account for each item group.

Generally, I advise my clients to use the Item group field on a product solely for the purpose of linking the inventory ledger and the general ledger. In my experience it should not be used for statistical purposes. You can use other fields for that.

As an example I could have the following item groups in my configuration:

  • Item group 10 = Traded items
  • Item group 20 = Services
  • Item group 30 = Semi-finished items
  • Item group 40 = Manufactured items
  • Item group 50 = Consumables

These would cover most normal scenarios in a small manufacturing company and allow me to reconcile the ledgers on a fairly granular basis.

Item Model Group

Inventory management / Setup / Inventory / Item model groups

Now you have defined how the general ledger and the inventory ledger relate to each other. You have also assigned products to their item group thereby implicitly linking them to the general ledger via the posting set up. Now, it is time to determine how the inventory cost of a product is treated. This is done by assigning the product to an Item model group.

Item model groups are configured in the Item model groups screen:

Item model groups.PNG

In the following, I will explain the main configuration options available on an Item model group:

Stocked product: This determines whether the cost of a product is posted to the balance sheet (ticked) or directly to cost-of-goods-sold (un-ticked) when posting a supplier invoice. If un-ticked, the system will not carry an inventory of this item. You must leave this field un-ticked for products such as stationary and consumables.

Post physical inventory: You must tick this option, if you would like the system to post goods-received-not-invoiced (GRNI) and goods-shipped-not-invoiced (GSNI). Also, this field needs to be ticked for products that are consumed in production, but need to go into work-in-progress (WIP).

Inventory model: This is probably the most important option to select on the Item model group. This determines how the cost of an item lot is calculated when re-calculating inventory on a periodic basis (see the first article in this series).

Physical / Financial negative inventory: These two fields can be tricky. Ideally, you would not allow the business to operate with negative inventory. However, in some cases, for instance when the goods receipt people are slow to update the system, goods may be physically shipped before they are financially updated. However, if possible, avoid allowing negative inventory.

The rest of the fields have limited impact on inventory costing or relate to special scenarios.

Dimension Link

Inventory management / Setup / Posting / Dimension link

If you have a requirement to track the internal ownership of inventory, you can configure this in the Dimension link screen:

Dimension link.PNG

Firstly, you must define which financial dimension is used to create the link. In the above example, I am using the BusinessUnit dimension. As the following example shows, each Site in the inventory breakdown structure must subsequently be associated with a BusinessUnit dimension value:

Site - Financial dimensions.PNG

Now, every time a transaction is made using Site 1, the system will post the cost value to the 001 (Home) BusinessUnit financial dimension.

Product Attributes

In its most simple form, you actually only need to set two attributes on a product namely Item group and Item model group to make inventory costing work. It really is that simple.

Further Reading

If you are interested in some of the theory and general concepts behind inventory costing, I can strongly recommend this book by Steven Bragg.

Summary

The basic configuration of the key elements of inventory costing in D365FO consists of item groups, the posting matrix and item model groups. Once you have those in place, you are set to go.

In the next instalment of this series, I will be looking at how to manage costs including

  • Maintaining standard cost prices.
  • Setting up charges.
  • Adjusting the inventory value.
  • The costing sheet.

 

Posted in Dynamics 365 for Finance and Operations | 1 Comment

The Last Suit You’ll ever Wear…

I have heard it said (and written) a few times recently that switching to a cloud-based ERP solution is the equivalent of MiB’s “Last Suit You’ll ever Wear”. As much as I sympathise with the sentiment, I do not necessarily agree with the underlying arguments that ERP replacement is predominantly driven by obsolete technology and that in this future Nirvana, replacing a granular part of ERP is like downloading an app for your new iPhone.

Judging by all the Dynamics AX 2009 and various old Axapta systems (not to mention Lawson M3, SAP R/something etc.) still running out there, I would argue that obsolete technology is low down the list of priorities for many companies. Albeit, I agree the future holds a more granular approach to ERP, the main reason companies have ERP systems is to support complex processes that span across this granularity. So, even though the technology will allow a more granular approach to implementation, the process complexity is not going to go away. It may actually increase as digital transformation extends traditional operational processes closer to the end-customer.

So no, I am sorry, a company will still re-implement their solution in 8 or 10 years time. And no, the decision will not predominantly be driven by obsolete technology and nor is it today. Here are some of the reasons I believe this to be the case:

  • In the digital era, a company’s business model will change more rapidly.
  • Acquisitions will lead to inefficient processes.
  • New management may see a re-implementation as a way to re-energise internal performance.
  • Cost pressures will lead us to think in new ways.
  • Organisations and processes change, the ERP system may not be able to support these changes without a re-think.

However, I think there is a lot of good reasons to move a company’s ERP to the cloud. Just to name a few:

  • Access to new and advanced technologies.
  • Increased security.
  • Predictable operational costs.
  • Scalability.
  • ERP becomes a technology commodity.
  • Technological complexity is abstracted away.

I agree that most companies are likely to stay on the same technology platform (including primary cloud service provider) once they have made the switch, but as much as I would love to think that in future we will only be making incremental changes to a company’s (everlasting) ERP solution, I think that business dynamics dictate a different reality.

Posted in Uncategorized | Leave a comment

Dynamics 365 for Finance and Operations Inventory Cost Model, Part 1: Core Concepts

This week I was encouraged by fellow networker, Wali Ullah Khan to share my insights on the inventory cost model in Dynamics 365 for Finance and Operations. On reflection, I agree that this topic is probably of interest to a quite a few people. Since this topic is relatively broad and complex, I have decided to divide my post into five parts, namely:

  • Part 1: Core concepts.
  • Part 2: Configuration.
  • Part 3: Cost management.
  • Part 4: Landed cost.
  • Part 5: Cost controlling.

The core inventory cost model has actually changed surprisingly little since the days of Damgaard Axapa 1.0. Actually, some of the core concepts of the inventory cost model go all the way back to Damgaard XAL. I have worked with this core model since 1995 (in Concorde XAL), but even so, I will not pretend to know everything, so if I get something wrong, please feel free to correct me. But this I know: we still have an inventory cost model that is tightly coupled to the application logic and data model.

In the following, I have tried to explain some of the core concepts in the D365FO inventory cost model.

Inventory Model

A released product in D365FO is associated with an inventory model through the Item model group. The inventory model determines how the inventory value for that product is calculated. D365FO supports a number of different inventory models, but some common scenarios are:

  • Traded products = FIFO.
  • Manufactured products = Standard cost.
  • Retail merchandise = Moving average.

Normally, the inventory model for a product is determined by the company’s accounting policy.

The inventory model for a released product is fixed for the entire legal entity, so it is not possible to change it by site or warehouse.

Inventory Transactions

The whole inventory costing system in D365FO revolves around the inventory transactions. Every time a product is bought, sold, manufactured, shipped etc. the system creates an inventory transaction (or updates an existing one). The same transaction may have a different status depending on where it is in the life-cycle. Some of these status values do not influence inventory costing, but some do. These are:

  • Received = The goods have been received and put away in the warehouse. Normally, this is referred to as goods-received-not-invoiced (GRNI).
  • Purchased = An invoice for the goods has been received and posted.
  • Deducted = The goods have been shipped to the customer, but not yet invoiced. Normally, this is referred to as goods-shipped-not-invoiced (GSNI).
  • Sold = The goods have been invoiced to the customer.

All other inventory transaction status value do not influence the cost.

Physical and Financial Value

Another important aspect of the inventory cost model in D365FO is the distinction between physical and financial value. Physical value is the value of goods received (status = Received) or goods shipped (status = Deducted). Correspondingly, financial value relates to status Purchases and Sold respectively. Historically, physical value was sometimes referred to as “floating value” in earlier versions (maybe it still is on some reports).

As the following screenshot shows, physical and financial value is recorded directly on the inventory transaction together with the physical and financial dates.

Physical-financial value.PNG

Average Value Issue

As the above example shows, the financial cost value for these goods is 188,790.00. However, depending on the product’s inventory model (see above), this may change when the inventory is closed (see below) on a periodic basis. If the product’s inventory model is set to Standard cost, the cost value is fixed and will not change when the inventory is closed. However, if a dynamic principle such as FIFO or Weighted average is chosen, the financial value may change. The change will be recorded in the Adjustment field on the transaction.

Closing

Ah yes, this lovely feature has been with us since Concorde XAL, so I guess it must be celebrating its silver jubilee. To calculate the true inventory cost value of products, you must close the inventory on a regular basis.

This also brings us to a very singular core concept of D365FO (and all its predecessors): issue at average value. When creating an outbound inventory transaction, for instance by creating a sales order, the inventory will not get a financial cost value until you invoice the sales order line. The invoice routine finds the cost value for the transaction by looking up the average cost value for the set of dimensions associated with the transaction. Let’s make an example:

Product 51B66 has a cost price €100 per piece. The storage dimensions for 51B66 are set to site and warehouse.

On warehouse WEST the company holds 50 pieces and the total cost value is €5,100. Therefore the average cost value for warehouse WEST is €102.

On warehouse EAST the company holds 25 pieces and the total cost value is €2,450. Therefore the average cost value for warehouse WEST id €98.

If the user invoices a transactions on warehouse WEST, the system will use €102 per item as cost of goods sold (COGS). If instead, the user invoices a transaction on warehouse EAST, the COGS is €98. In part 2 of this series, we will explore how to set up storage dimensions for inventory costing in more details.

As the following screenshot shows, you can always find the average cost price in the Cost price field on the On-hand inventory screen:

On-hand.PNG

When closing the inventory, the system will recalculate the value for alle open inventory transactions. Open inventory means (financially) outbound inventory, which has not been matched with (financially) inbound inventory. If the product inventory model is FIFO, it will, as it says on the tin, calculate the cost value using a FIFO algorithm.

This calculation creates settlements. These settlements are in effect an audit trail for each inventory transaction that shows, in detail, how the inventory cost value is calculated. The accumulated adjustment in cost value is stored in the Adjustment field on the inventory transaction itself. We will be looking more into settlements and cost exploration in part 3.

Once an outbound inventory transaction has been fully settled, it is closed and the cost value is fixed (at last).

Charges

All inventory transactions with financial value will have a corresponding entry in the general ledger. In part 2 we will be exploring the relationship between the inventory module and the general ledger. However, a core concept worth highlighting at this stage is this: if you would like to adjust the inventory value, it is done through the inventory module – not by making manual postings to the general ledger accounts. At least, if you need to make manual adjustments, create a separate adjustment account and leave the automated postings on accounts where manual postings are not allowed.

As a principle, you can only influence the cost value on an outbound inventory transaction by changing the cost value of the matching inbound inventory transaction.

So how do you do that? Mainly by applying charges to the inbound transaction. Charges can be applied in a number of ways, but normally they are applied on the purchase order and subsequently on the supplier invoice. Charges are fully configurable and can be applied automatically or manually. Examples of common charges are freight and duty. However, an automated (percentage) charge for warehouse overheads can also be applied and included in the inventory cost value.

It is worth noting that the cost value on the inventory transaction is always in the base currency for the legal entity. Therefore, exchange change fluctuations can be quite hard to carry over into the inventory value.

Standard Costing

Since standard costing is probably the most straightforward inventory cost concept in D365FO I will not be dealing with it in this series. In future, I will dedicate a separate series on this topic instead. Stay tuned…

Closing remarks

In the above, I have tried to introduce some core inventory cost model concepts that apply to D365FO. In the many projects I have been involved with, the concept most people struggle with is this: the fact that COGS is not fixed when you invoice the customer. In part 3 we will discuss how to mitigate this issue as far as possible. Also, many people find reconciling inventory and the general ledger difficult. Again, if best practice is applied when setting up the solution, it should not be too bad. We will be taking a look at this in part 2 and 5 of this series.

A word of caution to end this first post in the series: if this goes wrong, it is usually very difficult to reconcile the ledgers and get back on the right track due to the sheer volume of transactions generated by the system. In past projects, I have always tried to make sure we would simulate an inventory closing procedure with reconciliation to iron out any issues before going live. It is definitely worth the effort.

Posted in Dynamics 365 for Finance and Operations | 9 Comments

Dispelling a few myths about Dynamics 365 for Finance and Operations

In my conversations with clients, existing users of Dynamics AX and partners, I have come across a few myths (or statements, if you like) that I think are worth discussing. In this post, I have picked on a few of them and done my best to explain, what I believe to be the reality.

Myth #1: It is not possible to customise Dynamics 365 for Finance and Operations because it is a cloud solution.

Reality: Albeit, Dynamics 365 for Finance and Operations is managed and operated in Microsoft Azure, it is, to all intents and purposes, a private deployment with its own configuration and customisations.

Myth #2: Microsoft is sealing the application, so the system can no longer be customised.

Reality: Far from it. With extensions, the eventing model, common data service and custom services, Dynamics is probably more open than at any time in the past. Yes, you need to follow certain patterns and no you will probably not be able to directly mess about with the code that calculates VAT, but is that a bad thing? Customisations of a certain nature may also become more expensive, but let’s be honest: some pretty shabby customisations have been developed in the past because it could be done on the cheap (overlaying).

Myth #3: Running in the cloud will be more expensive.

Reality: For some, maybe that is the case. But often we are comparing apples to pears. The security and compliance measures surrounding Dynamics 365 for Finance and Operations are second-to-none and probably far better than anything your current hosting partner can provide (with all due respect). Moving the licence from CAPEX to an OPEX subscription model will make it more visible, especially for customers, who have given up their BREP, but I doubt it will make it more expensive, but obviously each customer is different.

Myth #4: My data is not safe.

Reality: I will not pretend to be an expert on the regulatory issues relating to whether a company can let Microsoft store and process their data in a certain geography, but for most customers this question is irrelevant. I work mainly with European clients and when deploying Dynamics 365 for Finance and Operations under Microsoft’s standard online services terms, the primary and secondary data centres are both placed in Europe (Ireland and Holland to be precise). You can read more on the subject here. You can also read more on how Microsoft protects your data in the Azure Trust Centre.

Myth #5: It will be hard to get my data out.

Reality: If you decide to terminate your subscription, Microsoft standard terms guarantees that data is available for a 90-day period (after the subscription is terminated) where you can download data to your own data centre or a new cloud partner.

There are probably a lot more myths, uncertainties and questions out there, but these five I have come across a lot recently. Feel free to comment, if you disagree with some of my conclusions. Only through dialogue and fact-based information can we dispel myths and untruths.

Posted in Dynamics 365 for Finance and Operations | Leave a comment

Creating a Personal Workspace in Dynamics 365 for Finance and Operations

Workspaces is a pretty cool feature in Dynamics 365 for Finance and Operations (D365FO). As you probably know, D365FO comes with a number of pre-built workspaces, but it is so much nicer to create your own personal workspace, isn’t it? Yes it is! So here goes…

To get cracking we need to go to the dashboard, right-click and select Personalize. This brings up this form:

Create new workspace

Click on the + Add workspace option. This automatically creates a new workspace tile on the dashboard:

My workspace 1

You can now right-click on the tile and give the workspace tile a more appropriate name. In my example, I name the workspace “My customer workspace”.

For now, the workspace is totally blank, so I need to go and add some content.

Firstly, I go to the All customers screen and filter on wholesale customers (customer group = 10) as shown in the following screenshot:

Wholesales customers filter

By clicking on Options in the ribbon and selecting Add to workspace, I can now select the “My customers workspace” I created earlier. I now have the option to add the customer query to the workspace as a tile, a list or a hyperlink. In this case, it would make sense to add it as a list.

As the following screen shows, I now get an opportunity to customise the list before it is created in the workspace:

Add as list.PNG

I can choose to have a simple list (3 columns) or a tabular list (8 columns) and select the fields I would like to display.

Opening the “My customers workspace” from the dashboard, the list has now been added:

Workspace with list

Similarly, I would like to see customers with debt past due as a tile in my workspace, so I go to the Customers past due menu point in the Accounts receivable module. When I add this query to the workspace as a tile, I am given the option of showing a count of customers in the tile:

Customers past due

The resulting workspace now looks like this:

Workspace with list and tile.PNGIf you choose, you can now add PowerBI components to the workspace using the Open report catalog menu point in Options on the ribbon.

So far, I have not found a way to add normal (SSRS) reports to the workspace as a hyperlink.

This was a very short introduction to how you can create your own personal workspace in D365FO. And yes, it really is that simple.

 

Posted in Dynamics 365 for Finance and Operations, Uncategorized | Leave a comment