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.
