The Inside Microsoft Dynamics GP blog has started a series Feature of the Day posts for Microsoft Dynamics GP 2018 RTM; as the most recent versions have been, these posts are in the form of PowerPoint slides; I am reposting them here so they can be read more easily as well as adding my own commentary.
The series index for this series of posts is here.
The ninth Feature of the Day is a feature requested by Mariano Gomez and that is to rename the payment run windows.
So instead of them being named Check or Cheque, depending on the installed language pack, they will now be named Payment:
The windows which have been renamed are:
- Select Payables Checks -> Build Payments Batch
- Edit Payables Check Batch -> Edit Payment Batch
- Edit Payables Check -> Edit Vendor Payment
- Print Payables Checks -> Print Payment Documents
- Post Payables Checks -> Post Payment Documents
In the UK, virtually no-one uses cheques anymore; payments are made by BACS which is a form of EFT. Renaming these windows
In this series I am taking a look at how macros can be used to update data in Microsoft Dynamics GP.
Macros can be a quick and easy way of inserting or updating information in Microsoft Dynamics GP, but there are some limitations to macros which need to be considered before using them.
A macro works by recording the exact series of actions taken by the user after clicking record; this means it is best to practise the series of steps the macro should record before clicking record.
When the macro is played, it repeats the exact steps as recorded. The way I typically explain this to clients, is to say that the macro pretends to be them typing very quickly. Which is a fair description of what the macro does; it records any typing and then plays back the typing; depending on what actions were recorded in the macro, you will see windows open and close and fields typed into.
This means that when a macro is being played back, Microsoft Dynamics GP must retain cursor focus or the macro will crash.
A macro plays back the exact steps as recorded and does not tolerate any deviation; this means that if the macro plays back and encounters a difference, such as a popup message dialog, the macro will crash and stop running. Any data updated will remain updated, so restarting the macro will likely require updated data to be removed from the macro file.
A frequent question asked by users is if they can build in conditions within the macro. The short answer is no, you can't as macros simply play back a series of steps. There is a longer answer which I will cover when in the posts on producing a macro from a macro template using Excel and SQL.
When recording a macro which will open windows, it is best to use the drop down menus at the top to open the window, as using the area page menu will often fail as this used the exact mouse position; when users using the same macro have different access configured, the menu option will be in different locations and therefore cause the macro to fail.