Michael Weaver Business Solutions Senior Manager

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.

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.

Both reference and distribution reference fields in GP's GL can only handle a maximum of 30 characters. I understand why these fields were kept relatively small when the product was developed in the early 90's, but 25 years later my customers expect a little more space to write descriptive information. I suggest 50-100 characters would be more appropriate and certainly more useful.

NOTE: I have the same suggestion for the "Description" field on the Payables Transaction Entry window (also 30 char max), and probably many other fields in GP, but the GL ones seem to be the biggest problem for my customers.

Add an additional name field to the vendor maintenance window that represents the DBA information for vendors that need to report their 1099's this way. Then program the 1099 report to be smart enough to format the 1099's correctly depending on whether there is a value in the DBA name field or not.

I have dealt with DBA 1099 reporting a number of ways over many years for many clients (e.g. modifying the 1099 report to pull in the Address 3 or contact, or creating a conditional report that prints one thing if one address ID is detected and another thing if another is detected. There are probably many other workarounds as well, however simply adding a field to track this scenario seems to me to be a simple fix that would save a lot of people a lot of time and effort modifying their 1099 reports and/or updating their vendor addresses in ways that otherwise don't make a ton of sense.

Allocation accounts are great tools and can be especially powerful when utilizing Variable Allocation accounts in combination unit accounts that act as the breakdown accounts. However there are also some limitations and inefficiencies with using these tools at times. I have seen other ERP systems utilize a feature they call "Vectoring" which for all purposes is a type of allocation account, however the allocation percentages only apply to part of the GL Account. For example say you have a COA with two segments XXXXXX-XXXX with the first segment representing the natural account number and the second segment representing department. A vector would allow you to define percent allocations but just for one segment, that could then be used against any GL account. Let's say my vector is called "OH Allocation by Dept" and I define that 25% goes to department ACCT, 25% goes to SALE & 50% goes to MKTG. Once that is defined, I could then enter any GL account and my vector would split out the total amount amongst the various accounts in the vector, in this case by Department. I have customers who've shown me this type of functionality in other systems. As an example they can enter a payables invoice and code the total expense to one GL account, then apply one of their vectors and the system then splits out that one distribution to all of the departments associated with the vector, saving them a lot of time coding. The other big time saver here is that unlike defining allocation accounts, with vectors, they don't have to set one up for each and every GL account, which is a big drawback of GP's allocation accounts IMHO.