I’ve had a number of chats with customers over the past few months about the rationale behind the evolution of Property Intellect range from the original 2.x series to the current 3.x series so I thought it would be useful to write these up for the benefit of everyone. Note that this is my personal take on this, there is no ‘official’ position. This is a long post!
Let start by saying that Property Intellect 2.1 was a popular package – actually it was much more successful than anyone had originally envisaged, and got used in ways that we had never thought of, much less intended. When we began looking at how to take PI forward it became clear that there were a few requirements that came up as repeat themes from many users:
- Better accounts. The need for better account handling – particularly the need for cross-checking, and better reports with drill down capability;
- Better reporting, particularly the need to drill down on the make up of the reports;
- More storage fields with more space to enter into;
- It was difficult to understand where to start to get value back from the program – a lack of process-driven presentation;
- A desire to control what was shown on grids;
- Better mail merging;
- Better user level security (i.e. restricting who could do/see what);
- Better multi-user access and management;
- Vista compatible.
That’s quite a list, and it was pretty obvious that to even cover part of it we would need to do something a little more radical than simply tweak the existing code. The original code base for 2.1 was based on a completely different set of requirements and some points above are fundamentally different in nature to the existing way it worked. It would not have been possible to take the code and twist it that far without making a real unmaintainable mess – so the only sensible avenue was a complete re-write.
Lets look at a comparison of the two systems.
Comparison of Architectures: 2.1 vs. 3.x
The table below is a broad comparison of the capabilities/perspective of each system:
|
2.1 |
3.x |
| Accounting |
Simple transaction records represent income/expenditure
Pros: Very simple and quick. Very lose validation requirements.
Cons: Mistakes easily made and difficult to trace. No proper account structure means anything but simple entries need ‘creative’ thinking to work around. Impossible to track certain accounting scenarios such as tenants moving from one property to another. |
Dual entry accounting
Pros: Controlled entry so much less chance of inconsistent accounts. Able to handle all accounting scenarios. Separation of account types permits more appropriate handling of the account.
Cons: More complex entry, stricter entry requirements – user must enter all required data there and then. Developer must provide all possible accounting paths. |
| Validation |
Very little field or record level validation, with only one or two required fields. Little or no cross checking on related data during deletion or modification.
Pros: Very simple and quick.
Cons: Can delete/modify data relied upon in other sections of the program leading to inconsistent/unexpected results |
Strong field and record level validation, with more required fields. Significant cross checking on related data during deletion or modification.
Pros: Prevents inconsistent data.
Cons: Slower initial entry and more work to process by the system. |
| Data Duplication
|
Duplicate records permitted.
Pros: Simple to enter data.
Cons: Usually ends up with multiple records (e.g. 3 contacts with the same name) leading to endless confusion, particularly when there is more than one person entering data |
Duplicate records with the same name not permitted.
Pros: Impossible to enter duplicates – user is forced to use correct record. Data always consistent.
Cons: Initially more confusing, small training issue. |
| Interface
|
Single page entry using on-page form.
Pros: Simple and fast selection and entry.
Cons: Severe restrictions on screen space available for fields. Difficult to implement sub-forms. |
Core sections supported by multiple windows that can be opened/closed as required.
Pros: Standard design familiar to most users. Significantly more space to add fields, sub-forms and other text/graphics.
Cons: Culture shock for 2.1 users. Slower than on page forms. |
| Data Storage
|
Single page entry using on-page form.
Pros: Simple and fast selection and entry.
Cons: Severe restrictions on screen space available for fields. Difficult to implement sub-forms. |
Core sections supported by multiple windows that can be opened/closed as required.
Pros: Standard design familiar to most users. Significantly more space to add fields, sub-forms and other text/graphics.
Cons: Culture shock for 2.1 users. Slower than on page forms. |
| Networking
|
Simple multi-user to Access back end with no accounts or permissions.
Pros: Simple installation/implementation.
Cons: All but impossible to coordinate clients, reliant on crude screen refreshes. Unable to see other changes until whole area refreshed. Failure in one client can crash/corrupt entire data file. No security. |
Sophisticated networking co-ordination with SQL Server back end.
Pros: Clients can see changes as they occur, not reliant on refreshes. Failure of any client will not corrupt data or affect other clients. User-level security.
Cons: More complex installation, more affected to misconfigured firewalls. |
| Scalability
|
Limited by Access back end.
Pros: None I can think of.
Cons: effectively max 5-10 clients. Performance degrades rapidly as number of clients increases. |
Highly scalable.
Pros: Back end is scalable as required. Can upgrade processing to provide additional horsepower without changing software. Performance less of an issue.
Cons: None. |
Essentially, 2.1 a great tool for a single user to quickly enter unvalidated data. The onus is on the user to make sure what they do is correct which makes it very open and flexible. The problem is that virtually nobody has the rigorous processes to ensure that data gets entered 100% all the time. Now, of course when we go to report on that data the old maxim ‘rubbish in, rubbish out’ applies in spades. Without control over the data it can be difficult to know where the data you see comes from.
Version 3 is much more sophisticated on just about every front – in its handling of data through to its reporting mechanisms. That means that we could expand the system to previously unimaginable levels safe in the knowledge that we would not break the whole system.
So far, so good. Now the downside for existing 2.1 users. The title of this piece refers to the saying ‘you can’t make an omelette without breaking eggs’, and that’s exactly what happened here. We could not maintain 100% compatibility between the two versions whilst implementing the new features and accounting standards. This wasn’t so much a technical limitation but rather that some information that is required by the accounting system in 3.x is simply not present because the accounting concepts required do not exist in 2.1. This all means that the import tool in some cases has to ‘fill in’ the blanks.
There are also some more fundamental changes to the way in which income and expenditure are handled. Let’s summarise again:
|
2.1 |
3.x |
| Rental income
|
Assigned directly to the payor and property. |
Payment is credited to the Tenancy account (new concept for 3.x). Property and Payor have no direct relevance to the accounting process but are linked for reporting purposes. |
| Property income
|
Assigned directly to the property. |
Not supported. |
| Expenses
|
Stored as a transaction with the payee as the supplier. |
All suppliers have accounts (new concept for 3.x). All expenditure must have an invoice and payment against that invoice. |
When building a tenant statement in 2.1, the system looks to the transactions and attempts to build a history, at which point 2 important limitations become apparent: if the payor is not always the tenant, how can you know what they paid? Perhaps look to the property association? No help there either – that does not really tell us what what being paid off so we’re left having to make assumptions about the transaction. If that tenant later moves to another property you own then things get even worse! As you can see, this can make the importer’s job rather hard indeed.
The concept of assigning income (rental or otherwise) to a property has been dropped completely from 3.x. If you think about it it actually makes no sense – a property is a physical asset (or profit centre if you like), not an account. Rental income is assigned to the Tenancy account instead, which means that anyone can pay the rent without messing up our interpretation of the accounts. Likewise, the status of suppliers is more defined in 3.x with each one having a proper account – we are not forced to infer that the person is a supplier based on the transaction attributes. The simple transaction concept also falls short as it cannot distinguish between invoices you have received but not paid and expenses you paid there and then – you as the user are forced to make up your own system in this regard…not very satisfactory.
Of course, none of these new concepts are in any way new – accountants have been using them for years. Our challenge was to present a more formal processes in an understandable way (we’re not trying to reinvent Sage).
Validation
This is a big issue and marks a sea change in the way that the systems work. 2.1 is a very ‘lose’ system in that you can enter the bare minimum to create a record then come back later to fill in the details. Perhaps more importantly, there is very little cross-checking between records (known in the trade as ‘referential integrity’). You can merrily delete a record that has a link to it from some other record. This does have some big advantages – it allows you to make the change, then go back and update the link with very little effort. However, in practice unless the user is extremely careful it allows major consistency issues in the data to appear.
Given our primary requirement to produce rock solid accounts, it effectively precluded the above approach – you simply cannot do it unless you are 100% confident in the data you are working on. From a 2.1 to 3.x migration perspective then we have more problems if the user has not entered the required data or the data is invalid in any way – in this case all we can do is reject that item and not import it. There is no ’silver bullet’ here.
Correcting Mistakes (digressing for a moment…)
The discussion before regarding validation has one interesting other spin-off – correcting mistakes. In 2.1 there are virtually no ‘business processes’ handled by the system, but in 3.x the opposite is true. Sticking to our maxim of good accounting means that we must process certain actions to manage the state of the accounts. Now some processes are reversible and some are not (at least not without disproportionate effort and code complexity) so it is not always possible to simply change the value of a transaction in the way you could in 2.1 – to do so could cause serious inconsistencies in the accounts. Lets take an example of a non-reversible business process:
- Tenant is in arrears by £50
- Further rent charge raised for £100
- Tenant pays us £75 and the system allocates the payment.
- The first £50 pays off the arrears, the next £25 pays off a portion of the rent owing from step 2.
Fine so far, but lets say the user made a mistake – it wasn’t £75 – we actually received £70. Our first instinct is to simply change the value of the amount received, but upon closer consideration we can see that that isn’t going to work as the system has taken that money and allocated it to various other places and accounts – the single action from our perspective has had repercussions on multiple accounts. To change the amount received we need to update all the affected accounts, which involves us looking back up the chain of events and ‘unwinding’ the process before remaking it.
Accounts are fun aren’t they? The system does this for you in most common scenarios but there may be some that it is not viable to do.
Summary
If you’ve made it this far you probably can appreciate the amount of time and effort that went into the 3.x series. When we set out, the choice was clear to us: in order to create the application that we envisaged – and was demanded by users – we had to start over, even if that meant a more difficult import process than otherwise would have been the case. I hope I have shed some light on the thought process behind it, but I’d love to see and address comments from 2.1 users (especially if they have migrated to 3.1!).
