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’ll compare how purchase holds work in both Dynamics GP and Dynamics 365 Business Central. Both products offer solutions for applying holds at a document and Vendor level, however there are differences which we can explore.
Dynamics GP
In Dynamics GP you apply holds to individual transactions via the “Transactions > Purchasing > Holds” window.
By placing the document on hold you won’t be able to pay this via a manual payment or the automated “Select Cheques” routine (the Dynamics 365 Business Central equivalent being “Suggested Payment” batch job).
Therefore you must remove the Hold via this window in order to pay the document.
You can also produce a list of documents on Hold via a Smartlist prior to creating a payment run to assist with the process.
If you wish to prevent any documents from being paid on a particular Vendor you can tick the “Hold” flag on the Vendor Maintenance window as per below:
Placing the Vendor on Hold will prevent any payments being issued however you will still be able to enter and post transactions other than payments.
Dynamics 365 Business Central
To place a document on hold you go to “Vendor Ledger Entries” and click “Edit List”.
You then enter any 3 characters in the “On Hold” field to indicate the document is on hold. For example below I’ve entered the characters “GW” in the On Hold column.
Although you can use any 3 characters we tend to suggest using users initials as this gives the added benefit of knowing who has placed the document on hold. You can also filter the “Vendor Ledger Entries” either on initials or whether the field is blank or not to identify which documents are on hold (i.e. add a filter for On Hold <>’)
When you add the 3 characters to the On Hold field this excludes the document from being picked up by the “Suggest Payments” batch job in the Payment Journal however you can still pay and apply the document manually. This is different to Dynamics GP which requires the Hold flag to be removed before it can paid.
You can prevent any payment to the Vendor via the “Blocked” field on the Vendor Page.
You can prevent all payments from being made by selecting “Payment” or prevent any transaction from being posted on the Vendor by choosing “All”. This differs to Dynamics GP as even if a Vendor is placed on Hold you are only prevented from posting payments.
Conclusion
Both Dynamics products offer robust solutions for applying document and vendor holds. The main difference seems to be that Dynamics GP gives the user the ability to ensure a single document won’t be paid, even via a manual payment, and Dynamics 365 Business Central gives flexibility to prevent all document types being posted against a blocked Vendor.
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’ll compare Dynamics GP Class ID’s to Dynamics 365 Business Central Templates. Both offer a method to quickly setup static data like customers and vendors however as usual both offer slightly different features and functionality.
Dynamics GP – Class ID’s
When creating static data like customers or vendors in Dynamics GP you can use Class IDs to make the process more efficient. As the Class ID is stored on the customer card, we also generally advise to create Class’s as a way to group together similar customers or vendors.
Below is the Debtor “Class ID” that can be used for defaults when setting up Customers in Dynamics GP. (this is accessed via the “Tools > Setup > Sales > Debtor Class” menu option)
As you can see various options can be set on the Class that the customer will then inherit if its assigned this Class. Things like the payment terms, the credit limit, currency and so on. We also specify the default GL codes that can should be used.
Once its setup you physically assign the Class ID to your customers as per below and the customer will inherit the settings from the Class ID.
You can then make any tweaks to the customer setup after the settings from the Class have been copied. For example you may wish to have slightly different discount on this debtor to what was on the Class ID.
One interesting feature of the Class ID is, if you make a specific change on the Class ID you can then roll this down to all Customers that are assigned this Class. (or not if you prefer). For example you may change the Sales Person on a Class and roll this change down to all Customers in the Class and only this change will be rolled down. (therefore other tweaks you had made on the Customer would be unaffected)
As the Class ID is physically stored against the customer you can also run certain reports by Class ID such as the various trial balance reports.
Dynamics 365 Business Central – Templates
In Dynamics 365 Business Central we can use “Templates” to assist in creating static data such as customers and vendors.
To do this I can select “Actions > Functions > Templates” when in a customer page.
Next I can click “Actions > New Document > New”
This would present me with a “Customer Template” I can create as per below:
In this page I can set things like default payment terms, currency codes and also posting groups for GL codes.
Once I’ve entered the default information on the template I can select this when creating new customers so those settings are inherited. I can also then edit and tweak any settings that are specific to this customer.
**Please note the template you used to create a customer isn’t saved on the customer.
Also, if I’ve accidentally assigned the incorrect template to a customer I can reapply another template via the option below whilst in the customer page
I can also create a new template based on the settings of a customer that’s already been created (or any existing customer). To do this I’d select the option below in the customer page:
Conclusion
Both Dynamics GP and Dynamics 365 Business Central offer great solutions to improve the efficiency of entering static data.
The difference with Dynamics GP is the Class ID stays with the customer enabling you to group certain debtors and run reports based on certain Classes whereas the template is just used to copy information to the customer.
Another interesting feature of Class Ids in Dynamics GP is the ability to change the Class and roll down any changes to the associated debtors.
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.
The Dynamics Explorer 