Search options (Page 2 of 2)

joe,

I understand this is the way it works...

I just don't uderstand how should 13 be between 1 and 2, if it is on the same level. 13 is higher than 2, or? ;-)

I think that within the same level IDs should be compared as numbers, not strings (where 13 comes before 2, as 1 is lower than 2...). Sublevels are something else, as it is common practice in accounting to add digits on the right side...

And, I don't understand your suggestion to rearrange group_id - to achieve what? I can do whatever I want with IDs, they will still be ordered by class ID first (what I don't like). If you think this is how it should be (without changing it, or give us an option to disable / change that), I will have to patch my code (probably just one SQL to be edited or so - haven't take a look yet). Altough I hate to do that (unless really necessary), it should make us all happy...

Hi Joe,

it is default empty installation. I've set CVS version just to test this feature, as it is very important to me (otherwise, I am evaluating 2.2.7 version).

So, the only difference is (copied from backup):

### Data of table `0_chart_types` ###
INSERT INTO `0_chart_types` VALUES ('1', 'Current Assets', '1', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('2', 'Inventory Assets', '1', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('3', 'Capital Assets', '1', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('4', 'Current Liabilities', '2', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('5', 'Long Term Liabilities', '2', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('6', 'Share Capital', '2', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('7', 'Retained Earnings', '2', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('8', 'Sales Revenue', '3', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('9', 'Other Revenue', '3', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('10', 'Cost of Goods Sold', '4', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('11', 'Payroll Expenses', '4', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('12', 'General & Administrative expenses', '4', '-1', '0');
INSERT INTO `0_chart_types` VALUES ('0', 'level 1 - TEST', '1', '', '0');
INSERT INTO `0_chart_types` VALUES ('00', 'level 2 - TEST1', '1', '0', '0');
INSERT INTO `0_chart_types` VALUES ('000', 'level 3 - TEST1-1', '1', '00', '0');
INSERT INTO `0_chart_types` VALUES ('01', 'level 2 - TEST2', '1', '0', '0');
INSERT INTO `0_chart_types` VALUES ('010', 'level 3 - TEST2-1', '1', '01', '0');
INSERT INTO `0_chart_types` VALUES ('001', 'level 3 - TEST1-2', '1', '00', '0');
INSERT INTO `0_chart_types` VALUES ('011', 'level 3 - TEST2-2', '1', '01', '0');

Up to Administrative expenses (12) it is a default, the rest is everything I've added. If there is a need, I can send you a complete backup and screenshot, but it was easier to simply copy/paste an extract from a backup (just made for this purpose) here...

None is OK, but 0 should be in front of 1 (both are Assets...), or?

And, 0 should be followed by 00, 000, 001, 01, 010, 111 by my opinion. Imagine you have about 25 groups or more of the same type, all mixed (not sorted...) and with quite similar names... If they are ordered as in COA, it would be much easier to find the right one.

And, what is the reason that groups are ordered by class type? I mean, if the national chart of account is not sorted this way, why not to allow it to be matched? Isn't it why IDs are there for - to manage the sort order with them? It can be by class types or not, as one desires. Wouldn't it be better this way (it can suit anyone...)?

Changing class types seems to work well now, thank you.

Subgroup parent list seems to be a bit unodrered though. Could be unpleaseant if there are many groups (a long list), with similar names (titles). Probably the order shall be by Group ID, considering level order as well (as it would be in a table above if it wouldn't be odrered by class types first). I am attaching a screenshot.

What about (an option to have) account groups ordered by "Group ID" (instead of "Class Type") in a table displayed? Shall I put this in feature requests?

Hi,

I've set all subgroups (00 / 000) to None (empty) through web interface (went well).

After, when I've tried to set group 0 as a parent of 00, I've got (well known): "You cannot set an account group to be a subgroup of itself.".

So, there seems to be some "numeric" check remaining, which is causing this (annoying) error report...

Editing database manually (not with phpMyAdmin, which is quite slow sometimes...; I prefer HeidiSQL, and suggest it to the others as well) seems to do the trick (table is now displayed well), but this bug can probably not be considered as 100% resolved yet (since we can not edit account types through the web interface...).

In next days, I'll try to see how it behaves (in other activities than just enter / edit it...).

Thanks & regards,

LUTi

joe,

that's all I've found:
---
Allow using of multi level sub-types when digits are of same length in account types

The current account types setup with sub-levels only allowed 2 levels in the current system.

By setting up the account types with same digit lenghts in id and exactly in the order you want them presented in COA and reports and with the sub-levels you want them belong to it is now possible to use at least 4 or 5 levels. Having more is not appropriate.

Condition for doing that:

Set the variable, $use_new_account_types = 1; in your config.php
---

It is not an example, just a (brief) description of the setting... BTW, it is more or less just the same as introduction of this setting (feature) in NEWS:
https://frontaccounting.com/wbt/pages/posts/release-2.2.3121.php

I believe Kalido has seen that already (as I did), but asked for an example to understand exactly what one can achieve through this setting.

Or, is the only difference that with this setting we have now a possibility to construct 4-5 levels of classes instead of only 2 (as until now)?

In this case, why this is an option at all? To be more precise, am I loosing something if I set this option to 1 altough I have (need) only 2 levels? If not, why would it be good to have it set to 0 at all?

I support the idea to have character IDs. This way, we can distinguish between 0 and 00, which are used in some countries as well (I am from Slovenia, and we have fixed assets in class / type 0 and 00).

Maybe there can still be an option to use IDs as "numeric" (so, strings are converted to their values first...), if this functionality is not needed (and, would help anyhow). Or, to have an extra field (and, use one or another) in the same table, or 2 different tables...