Topic: Dimensions enhancements

It would be great to have three dimensions available instead of two ... we keep track of business units, departments, and individual projects.

Also, if parent heirarchy could be added to dimensions like GL Account Groups.  We have two main business units but within those business units we have three or more areas within those business units.  If I could set up those areas as having the parent of Business Unit "A" or Business Unit "B" it would give me more flexibility in running reports by the areas or general business units.

Re: Dimensions enhancements

I personally think Dimension should be dynamic so we can have as many as we want. But as of now Dimension is hardcoded to only have a maximum of two.
We can set the amount of Dimension used in Company setup. You can see this in /admin/company_preferences.php

number_list_row(_("Use Dimensions:"), 'use_dimension', null, 0, 2);

The limit number 2 is hardcoded, like a "magic number". I don't think this is a good practice.

Even if you change that number (for example I tried 4) and set the company Dimension to larger than 2 (for example 3), many codes that deal with Dimension usually only check whether the Dimension is 1, 2, or neither. So any number of Dimension larger than 2 (or whatever beside 1 and 2) is treated as 0 (use no Dimension).

For example, let's take a look at the function used to generate the table in Journal Entry
/gl/includes/ui/gl_journal_ui.inc

function display_gl_items($title, &$order)
{
...
    $dim = get_company_pref('use_dimension');
...
    if ($dim == 2)
        $th = array(_("Account Code"), _("Account Description"), _("Dimension")." 1",
            _("Dimension")." 2", _("Debit"), _("Credit"), _("Memo"), "");
    else if ($dim == 1)
        $th = array(_("Account Code"), _("Account Description"), _("Dimension"),
            _("Debit"), _("Credit"), _("Memo"), "");
    else
        $th = array(_("Account Code"), _("Account Description"),
            _("Debit"), _("Credit"), _("Memo"), "");
...
            if ($dim >= 1)
                   label_cell(get_dimension_string($item->dimension_id, true));
            if ($dim > 1)
                   label_cell(get_dimension_string($item->dimension2_id, true));
...

In the above code we can see that the function only handle up to 2 Dimension, beside that will be treated as no Dimension.

So, if you want to change this behavior, you have to change every code that uses

get_company_pref('use_dimension');

I don't know why the FA developer decides to use a maximum of 2 Dimension instead of preparing for dynamic number of Dimensions. Could somebody please explain to us?

Thanks.
kuro

Regards, [url=http://captainkuro.com]captain_kuro[/url]

Re: Dimensions enhancements

For SME sized companies 2 dimensions are more than adequate. You can get a lot of GL reports where you can get the result on 2 levels.
If you have level 1 as departments and 2 as cost centres, you can get result for department X, cost centre Y. Or department X only.

Consider using Tags if you need more filtering.

/Joe

Re: Dimensions enhancements

Joe is original designer of dimensions feature, but I think I can roughly explain the reason. Even with 2 dimensions active it is difficult to keep entry forms layouts properly formatted. More dimension selectors would brake the screen view in many places. Also even when dimensions are used, still not all documents needs this data, but once switched on, they suffer user input performance all the time. The more not used ui controls, the worse data entry performance.
Last but not least tags are more universal, but still not very often used, so if anybody has spare resources and need for more sophisticated costs/sales categorization, development in tags area is much more promissing than extensing dimensions count to infinity.
Janusz

Re: Dimensions enhancements

Ops, seems our answers have overlapped smile
Jansuz

Re: Dimensions enhancements

Getting serious Dimension reports can not be done with use of dynamic dimensions. To get correctly P&L stqatements you must have the transactions sequential on the line (or in a table of its own with secondary keys).
Account - Dimension 1 - Dimension 2. Transactions belonging to Level 1, Dimension 1, and Level 2, Dimension 2 must be on the same transaction line and the account must be here too.

It would require enormous recursions with multi level of parents. And it would be impossible to handle these operations in the various forms.

/Joe