On the FA Transfer Maintenance window, you can transfer the Physical Location, Location ID, G/L Accounts, Master Asset ID & Structure ID, which is all good. However this would be much more powerful and simpler if you could transfer the asset class as well.
Classes are frequently linked to Account Groups in a GP deployment so that when a class is assigned to an asset, the associated account group gets assigned and the assets inherits the appropriate GL accounts.
Most of our customers setup their classes to represent both the asset class and the location, so for example FF&E-NORTH, FF&E-SOUTH, etc... They do this because their COA contains separate accounts for FF&E depending on the location. Since both the asset class and the location are part of the class, they can then setup matching Account Groups, and once again by simply adding the class to a new asset, the appropriate accounts get assigned.
So in the above scenario, it is very common to need to move an asset from one class to another, either because it was coded incorrectly initially, or more commonly, because the asset physically moved from one location to another.
For example, a new desk was setup as FF&E-NORTH and depreciated for a number of months, but then it was moved to FF&E-SOUTH. Doing a transfer of this asset allows us to transfer any of the fields mentioned above. Most importantly it creates the GL distributions to move the Cost and Accumulated balances plus it assigns the new GL accounts to the asset, which is all good. However, it does not change the class of the asset, which in the above scenario is necessary. So after the transfer is done, we then have to pull up the general window and manually change the asset class.
Not only is this an extra step that is easy to forget, but it also adds confusion to the entire process. If someone forgets the proper sequence and changes the class first and then does the transfer, that is typically problematic because changing the class will very likely also update the GL accounts with the new GL accounts because of the linked account group. Then when they go to transfer the asset, GP already has the updated GL accounts on the asset therefore you can't transfer them. It seems to me that simply adding the class id to the transfer window would solve all of these problems.
When trying to post FA to General Ledger (i.e. MDGP>>Tools>>Routines>>FA>>GL Posting), if any of the GL accounts in the batch are inactive, you cannot post and receive a message that some of the accounts are inactive.
However, there doesn't appear to be any notification of which inactive accounts are the problem. Including the problem account(s) along with the rest of the message would be ideal. If that is not possible, then providing some other means of easily identifying the inactive accounts in the FA batch would be helpful.
Our workaround of dumping the edit list to excel and then doing a vlookup against a list of inactive accounts wasn't too difficult, but nevertheless is a bit time consuming and should be unnecessary IMHO.
Currently workflow mails show amounts to 5 decimal places and this is difficult to read and work with. Decimal places should be either 2 decimal places or pick up from the currency setup.
The whole Send to Email functionality in GP is complex, not well documented and there is room for a lot of improvement. Due to the complexity and lack of documentation it takes a long time to troubleshoot these issues for what is a basic feature.
If I can setup a printer to send PDFs via SMTP in 5 minutes, why can’t I do this with GP?
There are so many dependencies to get Send to email to work (not all GPs fault) however what is in control of GP is the documentation, functionality, error reporting and notifications.
1) If you use Exchange Web Services to send to Email then you lose the ability to send PDFs.
2) If you use MAPI to send to Email with PDF you are forced to use Office 32bit (MAPI limitation) however almost everyone is forced to use MAPI because of the inability for Exchange to send PDFs.
3) No SMTP support? It is standard practice for Printers to send PDFs by SMTP, why is SMTP not supported in GP - this would remove the dependency on MAPI and 32 bit Office.
4) Notifications are poor - Emails are marked as sent successfully when they leave GP, if there is an issue with your template the email will fail to send but you will get no error message back from GP.
5) Logging is very poor - when sending an email all you get are the start and finish times of the job, there is no feedback after the command is sent from GP - no reporting whether the template was generated successfully, no reporting on which template field failed, no reporting if there was an error back from EWS or Outlook.
Getting Send to Email to work is a pretty miserable experience of trial and error that needs improving.
Adding the capability to drag and drop files to attach them to transactions (typically images of invoices) within the various modules of GP, specifically, the payables module rather than having to open and attach an image/file.
A Project Accounting PO created off a Requisition must be allowed to be cancelled. Currently there is no way of cancelling a PO line or voiding or deleting a PO if a requisition that has project accounting on it was transferred into a PO. This is a bug which should be fixed as soon as possible.
The AA budget when exported appears on multiple lines with the budget total at top level and then down in to individual GL account level.
This means that to make the information useful the data has to be manipulated to remove superfluous lines.
It would be better to export the data on an individual GL account basis.
This mini-module has been neglected for years and at one point was being shown the door, supplanted by it's big brother AA, however many don't have the need nor want the complexity of deploying and maintaining AA. Since MDA doesn't seem to be completely going away anytime soon, how about adding a few features to it, like:
1. Make it work with some additional core modules that it currently does not, like bank reconciliation and Fixed Assets for example.
2. Add some functionality to make creating and assigning Analysis Groups to GL accounts a little less of a manual process (i.e. one at a time). How about and "Assign Analysis Groups by Account Range" feature.
3. Have MDA work with MR like it used to with FRx
When creating a new year in the Fiscal Periods Setup window, the system assumes the next year when defaulting the First Day/Last Day dates. If a client is adding history after going live, they may need to add historical years. Suggested update: read the year field to decide what First Day/Last Day to default.
Add a checkbox in the Fixed Assets setup window (or maybe Posting Setup) to allow Fixed Asset posting to post "through" GL.