Account description hierarchy | CLEARIFY

Republishing an idea from the solution provider forum - If you are reading this and might use the feature, please comment so Clearify knows this would be useful to a broader audience.
-------------------------------------------------------------------------------------------------------------------------
The account hierarchy only uses account names today. If a user has the Description only option set and has hierarchies, they will not get the expected descriptions since all the hierarchies use the account name only. Suggest an option link QuickBooks (below) or alternatively a 2nd hierarchy using descriptions (probably with a coalesce function to avoid blanks.

What I am suggesting is that in the code that builds the views  you include 5 new fields similar to the below logic in a case where a user wants descriptions. i.e. Use a nested lookup to to the existing account table i.e. select min(gr1."Account Description") from QQubeUser.vd_AccountPL gr1 where gr1.[Account Name]= vd_AccountPL."Account NAME Grouping Mechanism - 1") as Acct_Desc_Group1

The full context is here:

SELECT
vd_Company."Company Name"
, vd_Class."Class Name"
, vd_AccountPL."Account PandL Grouping - A"
, vd_AccountPL."Account PandL Grouping - B"
, vd_AccountPL."Account PandL Grouping - C"
, vd_AccountPL."Account PandL Grouping - D"
, vf_FINANCIALPLCLASS."Current Month Budget"
, vf_FINANCIALPLCLASS."Period 09 YTD Actuals"
, vf_FINANCIALPLCLASS."Period 09 YTD Budget"
,vd_AccountPL."Account NAME Grouping Mechanism - 1"
, (select min(gr1."Account Description") from QQubeUser.vd_AccountPL gr1 where gr1.[Account Name]= vd_AccountPL."Account NAME Grouping Mechanism - 1") as Acct_Desc_Group1
, vd_AccountPL."Account NAME Grouping Mechanism - 2"
, (select min(gr2."Account Description") from QQubeUser.vd_AccountPL gr2 where gr2.[Account Name]= vd_AccountPL."Account NAME Grouping Mechanism - 2") as Acct_Desc_Group2
, vd_AccountPL."Account NAME Grouping Mechanism - 3"
, (select min(gr3."Account Description") from QQubeUser.vd_AccountPL gr3 where gr3.[Account Name]= vd_AccountPL."Account NAME Grouping Mechanism - 3") as Acct_Desc_Group3
, vf_FINANCIALPLCLASS."Current Year-to-Last Month Actuals"
, vf_FINANCIALPLCLASS."Current Year-to-Last Month Budget"
FROM
QQubeUser.vd_AccountPL vd_AccountPL
, QQubeUser.vd_Class vd_Class
, QQubeUser.vd_Company vd_Company
, QQubeFinancials.vf_FINANCIALPLCLASS vf_FINANCIALPLCLASS
WHERE
vf_FINANCIALPLCLASS.LinkToAccountID = vd_AccountPL.LinkForAccountID
AND vf_FINANCIALPLCLASS.LinkToClassID = vd_Class.LinkForClassID
AND vf_FINANCIALPLCLASS.LinkToCompanyID = vd_Company.LinkForCompanyID

The reason for including this as a feature request (vs me just continuing with the code I have obviously already wrote) is that it would bring the product closer to parity with QuickBooks reporting and, more importantly because the Excel add-in  is a VERY useful tool and I would hate to tell my customers that they can not use that tool because the descriptions that they labored over writing are not supported.Of course, this would all be done within QQUBE and clicking (or not) on the "description only" in QB would have no effect.

I haven't had one person ask me to include a Account Description in any reports. Only Account number/name. 

So this would not be high on my list, but can see your point for parity.

What I do find confusing is having ALL of the Account tables.  Maybe AccountPL vs Account BS, but find any further refinement unnecessary and confining.  I know these were there before but just saying.  

The "master" account dimension if you will, has fields in it that are applicable for every situation.

Certain "pieces" of the account dimension are only applicable in certain instances.  

• BS Classification fields can only be used in a Balance Sheet
• PandL Classification fields can only be used in a Profit and Loss Statement

So the "master" account dimension would be applicable for General Ledger Detail.  But if you used that same "master" account dimension in a PandL Statement, you certainly would have no need for the BS Classification fields.

So yes, those make sense.

The reason we have the others, is not as obvious: we might have several account dimensions in the same FACT table. 

For instance the Sales analytic FACT table has an account dimension for sales, and another account dimension for COGS, and still another account dimension for summary accounts e.g. A/R where people might have multiple A/R Accounts.  So these three account dimensions must have aliases, as you can't have one account table being simultaneously used in three places.  Second, none of these three tables would need either the BS Classification fields OR the PandL Classification fields (and a few other inapplicable fields).

The table on this page shows where the various account dimensions are used: https://clearify.com/wiki/view/3316/dimension-details 

We have the opposite experience.

We are nonprofit accountants and issue monthly board reports. We are looking to QQube to speed up their preparation.

We prepare MOST of our client financial statements with the "Description Only" feature turned on. We use this field for the "pretty" name. It is a more professional presentation. The only time we use Account Number & Name is if the reports are for a finance or management committee as it may help with the budgeting process.

We abbreviate long account names to assist with correct posting. The main problem is, the account fields on QuickBooks transaction screens are too short. If we have a chart of accounts with sub-accounts, a user can get lost only seeing the beginning of long names.

For example, "Insurance" is spelled out in the description field but is "Ins" in the account name. 

   PPE = Property, Plant, and Equipment.

   COH = Cash on hand and on deposit.

We have many clients using sub-accounts to 5 levels -

   ER = Earned Revenue, A = Audiology, HA = Hearing Aids and ADJ = Adjustments. 

   Otherwise, we get -

  "Earned Revenue: Audiology: Hearing Aids: Adjustments: Contractual" or

  "Earned Revenue: Audiology: Hearing Aids: Adjustments: Discounts Given."

On 3/29/2018 3:33 PM, Fran Reed said:

I haven't had one person ask me to include a Account Description in any reports. Only Account number/name. 

So this would not be high on my list, but can see your point for parity.

What I do find confusing is having ALL of the Account tables.  Maybe AccountPL vs Account BS, but find any further refinement unnecessary and confining.  I know these were there before but just saying.  

This will be released in QQube 6.4 expected by end of September 2018