David.Simmonds wrote:I know Mike has some significant ideas that he is thinking about doing for the GL. The GL is probably one area where we could/will make wholesale changes. Things like easy to change periods, a less rigid account structure, Multi Company won't happen without BIG changes being made. More to come on this one.
The ideas I have currently kicking around are :
1. GL Account Types - GL Accounts being assigned a type (eg: Inventory Control, Debtors Control, etc), and when attaching an account to, say an Inventory item, only Inventory Control Account types are selectable
2. Period Templates - The ability to define any manner of period structure, which is overlaid on the raw transactions based on date, to summarise transactions by the nominated period. Many period templates may be created, and when viewing or reporting, you can nominate which template structure you wish to have them represented with
3. Analysis codes - similar in concept to custom fields in other areas - but simpler. The hope is we will allow raw data structure changes to a "GL Analysis" table - you can add as many columns as you like which relate to an account or group of accounts. Using raw table structures is easier to report on than custom field type structures.
You'd also need to be able to nominate which documents (PO, SO, etc) the particular analysis codes need to be captured on.
Example : You create an analysis code named "Salesman". This applies only to the accounts of type "Inventory Sales Value". You also stipulate it is captured on sales order lines.
On the sales order form, a new column appears "Salesman". You can either let the user select the value, key the value or perhaps a Solution will automatically set the value based on some logic. When the sales order is posted, the captured "Salesman" value is pushed through to the appropriate field in the GL Transaction Analysis table (a table we are yet to build - but one that simply has the GLTransID and a bunch of columns - being the analysis columns).
In theory, this would mean the reporting of, say - commissions for salesman, would be quite a simple report.
4. Company partitioning - every table has a CompanyID column - users can switch between companies, which are logically separated, but in the same database.
Inter-company transactions would then have a high degree of integrity (eg: PO in company A results in a SO in company B, etc). Presently it's rather messy to do such transactions, as SQL transactions are limited to within the same database.
Inter-company eliminations would also be a special form/module which would facilitate the accounting practice of eliminations.
5. GL Chart / structure. As per David's comment - he has some ideas on how this would look - it has been explained to me a few times, but right this moment the details escape me - but I do plan on spicing this up as per David's spec.
6. Granular Period Locks - period locking (ie: not being able to post to a period) to be more granular - ie: you can specify which modules are able / not able to post to particular periods.
Right now, the GL isn't in our sights, but certainly will be soon enough. I know when I get to the detail of Transaction Sets and coding all that up, we won't be able to resist the temptation to work some magic on the GL
- We'll certainly be posting a design document here on that also.