Dynamics GP Vs Dynamics 365 Business Central – Multi currency revaluation / Adjust Exchange Rates

Introduction

This is another blog in a series I’ve been writing comparing functionality in Dynamics GP to Dynamics 365 Business Central.

In this post I’m looking at multi currency revaluation in Dynamics GP compared with adjust exchange rates in Dynamics 365 Business Central.

Both routines perform the same task of revaluing foreign currency entries, and both are great and easy to use solutions, however I’ve found some key differences which I’ll highlight below.

** Please note this article doesn’t go into how rates are selected and what filters can be used. It focuses on the options available to revalue.

Dynamics GP

In Dynamics GP you run the revaluation using the “Multi currency Revaluation” window below:

The first thing to note is the revaluation routine is ran separately for the Financial (GL), Sales and Purchasing modules and for all three modules you can select to run a “Realised” or “Unrealised” revaluation.

In my experience a “Realised” revaluation is only ever ran on the financial series against G/L codes for foreign currency bank accounts. However the option exists to run a realised revaluation against the sales and purchase series as well.

** I suspect this would be useful if a sales or purchase transaction had either been outstanding on the ledger for a while, or was expected to be outstanding on the ledger for a while, and in that time a significant change in the exchange rate had, or would occur.

When you do run a “Realised” revaluation on the sales or purchasing series the functional (LCY) currency amounts are updated on the original transaction, and G/L entries are posted to the relevant realised exchange gains and losses accounts.

The “Unrealised” revaluation can also be ran against the Financial, Sales and Purchasing series however in my experience this is only generally ran against the Sales and Purchasing series.

Interestingly the “unrealised” revaluation can be ran with or without the “reversing” option being ticked.

With the option ticked entries are posted to the unrealised gains and losses accounts as expected however a reversing journal is also posted on the date specified backing out those postings. Also, when this is selected, the functional amounts (LCY amounts) on the original sales or purchasing transactions aren’t updated.

When the option for a reversing entry isn’t ticked the unrealised gains and losses are updated along with the functional amounts on the original transactions. When the transaction is applied the unrealised gains and losses are reversed and the realised gains and losses are updated. (in my experience this is the option that is most commonly used)

Finally you can also “print report only” prior to running the actual revaluation. This gives you a sneak preview of what would happen if you were to run the revaluation. I find this very useful and always recommend using this prior to posting the revaluation.

Dynamics 365 Business Central

The window below is used to run the “Adjust Exchange Rates” in Dynamics 365 Business Central:

The first thing to note is that in Dynamics 365 Business Central there’s no option to run the “Adjust Exchange Rates” separately for each ledger (or series).

There’s also no option to revalue the G/L codes other than the bank accounts. (which are revalued by adjusting the bank account ledger entries. The G/L entries aren’t affected)

** This is because interestingly unlike Dynamics GP the foreign currency amounts aren’t stored in the G/L Entries table. Only “additional currency amounts” are stored in the G/L entries….more on that later.

In also interesting to note that unlike Dynamics GP there’s no specific option to run a “realised” or “unrealised” revaluation.

When you run the “Adjust Exchange Rates” job and select “Adjust Customer, Vendor and Bank Accounts” the system posts adjustments to the “unrealised” gains and losses for the Customer and Vendor Ledger entries and to “realised” gains and losses accounts for bank accounts. Any “unrealised” gains and losses are tracked on the original transactions via “Detailed Ledger Entries”. As with Dynamics GP these are reversed when the transaction is applied and amounts posted to the “realised” exchange gains\losses accounts.

Dynamics 365 Business Central also offers the ability to record transactions in an “Additional Reporting Currency”. Although this is beyond the scope of this article, when this is configured amounts are posted to the G/L entries in the selected reporting currency using the current rate for the selected additional currency. Depending on the configuration of the G/L code these can be adjusted by selecting the option “Adjust G/L accounts for Add. Reporting Currency” in the “Adjust Exchange Rate” window as per above.

Although you can specify a reporting currency in Dynamics GP you can’t revalue it in the same way you can in Dynamics 365 Business Central.

Conclusion

I’ve found there are quite a number of differences in functionality between Dynamics GP and Dynamics 365 Business Central in this particular area.

For example you can’t run a realised revaluation of the Sales and Purchasing ledgers or revalue G/L codes other than bank accounts. There’s also no option to preview the potential posting prior to running the routine.

This said, in my experience, the functionality offered by Dynamics 365 Business Central would be adequate for all Dynamics GP users thinking of making the transition to Dynamics 365 Business Central.

** Please note based on my findings running the “Adjust Exchange Rates” job and selecting “Adjust Customer, Vendor and Bank Accounts” is the equivalent of running a realised revaluation on the financial series restricted to bank accounts, and running the unrealised revaluation in Dynamics GP on the Sales and Purchasing series and not ticking the “reversing” option.

I’d be interested to hear if anyone knows of users needing to run realised revaluations of the Sales and Purchasing ledgers and the reasons for this. Also if anyone runs an unrealised revaluation and marks the option to reverse this.

Thanks for reading!

Dynamics GP Vs Dynamics 365 Business Central – Account Segments and Dimensions

Introduction

This is another blog in a series I’ve been writing comparing functionality in Dynamics GP to Dynamics 365 Business Central.

In this post I’m looking at account segments in Dynamics GP compared with dimensions in Dynamics 365 Business Central.

The configuration of Dimensions and Account Segments can become quite a in depth subject, so in this post I’m just going to briefly outline what I regard as the basics in both products.

**Please note you can extend the analysis in Dynamics GP with Multi Dimensional Analysis (MDA) or Analytical Accounting (AA) which I won’t cover in detail in this post. For example you might require additional analysis for a particular project which can be achieved with MDA or AA.

Dynamics GP – Account Segments

Dynamics GP supports a traditional account structure using account segments to describe a General Ledger code. You can create a maximum of 10 segments and the combination of those segments is the General Ledger code itself. For example in the demo data that accompanies Dynamics GP the General Ledger account code is comprised of 3 segments. This is shown below in the “Account Format Setup” window:

In this configuration there’s a “natural” segment, or main segment, and then there’s segments for “Division” and “Department”.

These additional segments can be named in the “Account Segment Setup” window.

Therefore the GL code below of 300-6170-00 can be described as the Repairs & Maintenance code for the “Sales” department. (the Sales department being department 300)

As I’m used to this configuration I do find reporting off the back of this configuration quite easy, however I’ve found one drawback is if I want to create a new department I’d tend to create this for all combinations of the natural code, so could end up with lots more codes that might not be used.

Dynamics 365 Business Central – Dimensions

In Dynamics 365 Business Central the main account code is made up of one segment, which is the natural code, and additional dimensions are created for analysis.

You can create a maximum of 2 Global dimensions and an unlimited number of shortcut dimensions.

Global dimensions are special as they are stored on the ledger entry tables so can be used to easily filter and analyse data throughout the system whereas shortcut dimensions are stored in a sub table.

For example below is a GL code (6110) from the Cronus data in Dynamics 365 Business Central which is a Sales Code described in one segment.

I can then assign dimensions at Customers/Suppliers/GL Code level to add my extra analysis. For example I’ve assigned the dimension “Customer Group” to the customer below with a value of “Large”. (you can also edit the analysis prior to posting)

Now when I post a transaction for this customer the dimension analysis will be posted onto the Ledger Entry tables for the transaction so you can perform additional analysis. (** As mentioned above Global dimensions are stored on the main Ledger Entry tables and shortcut dimensions on a sub table)

If I was replicating the demo company account setup from Dynamics GP I’d have the natural segment as the GL account, and two dimensions. One for the department and one for the division.

There’s also the flexibility to make the dimensions mandatory, require the same default code to be used, or have no code entered.

Finally, you can also set code mandatory or defaults at the table level for speed of setup. For example, I could setup a default for the customers table, so all customers require analysis. i.e. below I’ve set the system so every customer needs analysis to the CUSTOMERGROUP dimension

Conclusion

I’m used to the account segments in Dynamics GP, so seeing and using dimensions did take a little getting used to. However all in all dimensions offer great flexibility and if used correctly can keep the chart of accounts clear and concise.

Thanks for reading!

Dynamics GP Vs Dynamics 365 Business Central – Managing Financial Periods

Introduction

Dynamics GP and Dynamics 365 Business Central both have great options to manage financial periods therefore controlling what date ranges users can post into.

In this post I’ll explore how this is achieved in both products, and point out what I think are the key benefits of each solution.

Dynamics GP

In Dynamics GP you can open and close financial periods using the “Financial Period Setup” window as per below

There’s a couple of key takeaways here:

  1. This is a global setting therefore the configuration of this window affects all users of the system. i.e. you can’t allow some users to post into certain periods on an individual basis.
  2. You can close the financial period for one series, (or ledger) while leaving another series open. For example, in the configuration above you can post a Sales transaction with a GL posting date of March, however you can’t post a Purchasing transaction with a GL posting date of March as that has been closed.

Dynamics 365 Business Central

In Dynamics 365 Business Central you can control allowed posting dates in two separate places.

The first is by entering a specific date range in the General Ledger Setup as per below.

The next is at user level via the User Setup window:

If you haven’t specified a user as having a different “Allowed Posting Date” range in the User Setup window then they are bound to the allowed posting dates in the General Ledger Setup.

The key takeaways here are:

  1. You can have different allowed posting dates for different users.
  2. You can’t completely close one series (ledger) and have another still open.

Conclusion

I think both systems have great features.

I love the way you have the flexibility to only close down certain series (ledgers) in Dynamics GP, as I imagine in the real world departments aren’t ready to close at the same time.

I also like how in Dynamics 365 Business Central we can close a financial period using the “General Ledger Setup” window for the majority of users however you can configure some users, for example a financial controller, to have the flexibility of posting across a larger date range.

Perhaps one day one of the products will incorporate both ideas 🙂

Thanks for reading!