I’ve spent the last few years designing systems@work’s time@work (for professional services management), expense@work (for expense management) and forms@work (for forms and workflow management), three highly configurable software packages all inspired by SunSystems financial and business software.
SunSystems was developed by colleagues of mine who formed Systems Union in the 1980s. It’s still the mainstay of LLP Group, a SunSystems reseller and consulting group which I founded in Prague in 1992.
SunSystems’ excellence lies in a few remarkably simple concepts:
- A single ‘unified ledger‘ handling accounts payable (AP), accounts receivable (AR), general ledger (GL) and fixed asset ledger transactions. Accounts of types Creditor, Debtor, Client (both Debtor and Creditor), Profit & Loss, Balance Sheet, and Memo accounts all co-exist in a single chart of accounts. The unified ledger idea actually spawned at least two well-known accounting software systems – CODA, and SunSystems, both British.
- The use of transaction analysis codes instead of structured general ledger codes for the purposes of management accounting and statutory reporting (VAT reporting, for example). An analysis code need be set up only once, and then selected and posted during journal entry to any account that is defined as requiring it. The chart of accounts thereby remains simple.
- The option to set up additional analysis on other entities (such as Account Codes and Asset Codes) for reporting purposes (this makes the translation of reports from corporate to local account codes easy, or vice versa)
- The use of parallel ledgers for budgeting or alternative treatments (e.g. alternative asset depreciations). Each user-definable budget ledger has the same structure as the ‘Actuals’ ledger.
- The option to enter ‘other amount’ and ‘currency code’ values on any transaction in any ledger (in the latest version of SunSystems you may enter five amount fiels and four currency codes)
- The use of additional ledger fields for asset codes, etc.
The result is an extremely simple, easy to understand, ‘flat’ structure (reflected in a non-normalised database) that is nevertheless extremely powerful and flexible. In terms of database tables, the essentials include:
- A Chart of Accounts table
- Ledger tables (an ‘Actuals’ ledger and a number of parallel ‘Budget’ ledgers)
- Optionally, a Fixed Assets table
Everything else is merely supportive.
The advantages are many:
- No issues reconciling AP, AR and GL
- Reporting tools that can range easily across transactions on any type of account and in any set of ledgers
- It’s easy to set up new analytical dimensions at any time
- It’s easy to handle multiple currencies (typically local currency values that must balance, transaction currency values (e.g. foreign expenses), and reporting currency values (enabling consolidation of several ledgers in a single corporate currency)
The product was also designed with language translation in mind – all textual terms being held in files external to the program files.
It’s not surprising that SunSystems remains an excellent choice for corporations planning to use a single system across the globe. It can be rapidly implemented in a standard way, meeting corporate and local requirements simultaneously.
I spent many years implementing SunSystems in many parts of the world and came to appreciate the powerful simplicity of its design. In designing time@work I adopted many of these ideas and in some cases took them one, necessary, step further:
- A single ‘Actuals’ ledger containing transactions of all kinds, whether originating in timesheets, forms, invoices, or attendance forms
- Any number of parallel ledgers of exactly the same structure for planning and other purposes
- Analysis values on transactions (the same set of 50 dimensions available for use on timesheets, forms, and invoices across all ledgers)
- Analysis on entities (Clients, Projects, Tasks, Employees)
- Multiple value fields on each transaction (20 values, and 20 ‘currency’ codes to identify the currency in which each value is expressed)
- Reporting tools that can range across multiple ledgers
- Data Dictionaries accessible to the end-user where different language texts are held, as well as industry specific textual alternatives (e.g. engagement, or case, instead of project)
Where I extended the design was to enable multi-company functionality in a single database, making it possible for an organisation to define one set of projects and one set of employees for use group-wide. In a professional services organisation this makes it easy for an employee belonging to one company to report time or expenses against a project belonging to another company, and makes it possible for an employee in one company to manage employees and projects in another, and to be involved in workflow regardless of the company to which an employee or project belongs.
Multi-company capability, though, implies at least the following:
- The need to handle multiple base currencies (an organisation may be operating in several countries but may still need to see employees and projects as a single pool). Holding the currency code on each of twenty values in every ledger transaction makes this possible.
- The need for multiple charts of accounts. When transactions must be sent from systems@work software to one or more finance systems the appropriate transactions for each company must be easily identifiable and must be constructed using the appropriate account codes for the destination ledger
- The need for separate invoice sequences
- The need for separate sets of expense types, each appropriately implying a general ledger code
Achieving all of this, whilst retaining simplicity on the surface has been our aim. The result is a set of simple components that can be assembled in millions of different ways to meet the needs of a wide range of organisations, without software modification.
systems@work works with any finance system, but it’s conceptual similarities with SunSystems makes it an ideal extension for timesheets, expenses, planning and billing. Contact me for more information.