WorkBook Architecture Summary
- Helen Johnson
- Nicky Harvey
- Kye Hush
In this article, you will find a summary of the overall architecture and the most important master data structures within WorkBook. This will help you understand how the different WorkBook data structures are related to each other, and how they can be leveraged for your needs.
ON THIS PAGE YOU WILL FIND: |
|---|
|
SYSTEM STRUCTURE
WorkBook is a multi-company, multi-currency system. It is structured in a way that allows for a record to sit in multiple hierarchies and have relationships to many different attributes, which provides the flexibility to report at different levels on the same set of data. The golden record that ties many attributes together is the Job. We will take a look at the main structures below, and for each structure, provide further information.
Application Overview
Company Structure
A company in WorkBook is usually the legal entity, particularly if the business is using WorkBook for its accounting. On occasion, the company structures may be set up differently to the entities, according to the specific needs of the agency.
Departments are flexible in their use: employees must belong to a single department, whereas optionally a job may also belong to a single department. For this reason, many agencies use (and rename) department to profit centre for the purposes of tracking office profitability and intra-office work.
Relating to the structure:
At least one operating company is mandatory in the system
Consolidation companies are used for the purposes of group reporting
A single operating company can relate to multiple consolidation companies, which allows for a flexible group reporting structure
Highlights of company-based structures and functionality:
WorkBook companies are subject to ‘cross-company user permissions’, which allow you to share resources and information across your different companies, and still keep data private where required
Each operating company has its own set of accounts, balance sheet, creditors, and debtors ledger
Whilst there is much configuration that lives at a database level or client level, there are also a number of company level configurations that allow a company to incorporate different structures and rules than the overall database. Such as:
Approval workflows
Financial posting rules
Business rules, such as default working hours or scheduling principles
Integrations, such as document storage and automated invoicing uploads
A consolidation company is used for reporting and has its own set of accounts. All companies linked to the consolidation company must have the accounts mapped into the consolidation company accounts
MASTER DATA STRUCTURES
Master data is the key data that lives across your organisation. We will explore some of the main concepts of the most used and most important master data structures in WorkBook.
The areas we will delve into are clients, vendors, dimensions, and activities.
The Client & Debtor Structure
The Client
The client is a reporting dimension that must be added to each job. The client is a ‘global’ record (not living within an individual company), although permissions can be set around who can access data for each client.
A job must be opened under a client, which means that you will also have at least one internal, new business, annual leave, and other-leave client for the purpose of time entry.
The client record holds a lot of data and business rules within WorkBook, these include:
Address details & client contacts lists
Default and 'allowed' price list/s (rate cards)
Approval rules
Default ‘dimensions’ (reporting attributes such as client group, client lead, or client segment
Staff permissions (for data protection, conflict management, and user experience)
The 'linked debtors’…
The Debtor
The debtor is the company that you send invoices to. In order to raise an invoice to a debtor, it must first be linked to a client. The relationship between debtors and clients can be 1:1, 1:Many, or Many:1. The debtor holds the billing entity name and address, sales tax settings, and other AR posting rules.
The Vendor & Creditor Structure
Like clients, the vendor (supplier) would also exist as two separate records. The vendors in WorkBook are the job-related suppliers that you would raise POs for. These are linked to creditors (the companies that you register creditor invoices against and then pay).
To state this simply; every record would exist as a creditor, but only your job-related suppliers would exist as a vendor.
The Vendor/Supplier Record
The vendor must exist in order to raise a purchase order for that vendor. The vendor contains a default activity and address details.
When an invoice is received against a PO, the invoice can automatically populate the creditor details from the PO. This is only possible if the vendor is linked to the creditor…
The Creditor record
The creditor record is what the actual invoices will be registered against in the system. There are tax details, payment details, some more complex approval workflows, and capabilities, and posting rules set up at the creditor level.
Employees each also have their own (linked) creditor record for the purpose of expense and mileage reimbursement.
Dimensions
Dimensions are powerful and customisable attributes that can be enabled on various records across the system. They can default onto certain records based on specific business rules. Some dimensions can also have workflows attached; such as revenue recognition rules, approval workflows, or the automatic application of job templates.
Dimensions can be reported all the way through to the P&L and balance sheet and so offer a scalable and dynamic alternative to traditional hierarchies such as accounts. This means you can run a P&L by client, division, industry, contract type, or revenue stream, amongst others.
Activities & Price Lists
An activity in WorkBook is a role, cost type or type of work within a job, e.g. Designer, Account Manager, Hosting, Travel, etc. Activities are used in estimates, time entry, cost of sales, and invoices to indicate the type of work performed. Each employee has a single default activity, but with configuration, can be allowed to log time to different activities. Time-based activities have an internal hourly cost assigned to them which, when combined with the price from the price list, informs the estimated net margin on a job.
You can apply specific ‘override’ posting rules to an activity. For example, if you wish to post account management income to a specific income account.
Activity Structure
Finally, activities are used to build price lists.
Price Lists
Price lists (rate cards) are built from activities and can contain hourly rates, unit cost price, and mark-ups depending upon the type of activity. They can optionally contain ‘exceptions’, meaning you can override the activity rate where specific people, positions, departments, or companies are completing the work.
A job always has a price list attached. Price lists can be global or unique to clients, or both. They can be in any currency. Every client must have access to at least one price list, and a default price list set against their profile.
Related articles
© Tangram 2022. All rights reserved.