Pushing Excel - Application Design 3181551508

Table of contents :
2A. General 3
2A.1 Excel can be used as: 6
2A.1a Be Careful What You Wish For! 6
2A.2 Applications 8
Facit Calculator (circa 1944) 8
2A.2a Development goes in cycles 13
2A.3 UI Design Objectives 14
2A.4 Change Control 15
2B. Structural Design Framework 16
2B.1 Framework 18
2B.2 Implement process and design methods 20
2B.3 Objectives 22
2B.4 User needs 24
2B.5 Key variables standing data 25
2B.6 Modules & steps (minimize number) 27
2B.7 Example of Design specs 31
2C Interface - Menus + Other User Interfaces 32
2C.1 Intuitive 32
2C.2 Logical 32
2C.3 Dropdowns List Technique 33
2C.4 Output – Reports 34
2C.5 Presentation and Format 35
2C.6 Navigation 37
2C.6a Aids to Navigation 39
2D Internal control system 44
2D.1 Dangerous current trends 44
2D.2 A 2020 operational paradox 45
2D.3 Totals 47
2D.3a Example: Total for a SUMIFS() Summary 47
2D.3b Example in action: Balance should be zero 49
2D.4 Agreement - Source & Destination 50
2D.4a Round-tripping 50
2D.4b Common key 50
2D.5 Reviews 51
2D.5a Review Summary 51
2D.5b Review Comparison to Expected Results 512D.5c Review Trends 51
2D.5d Review Accuracy of Calculations 51
2D.5e Review - Audit Area 51
2E. Documentation 55
2E.1Objectives 56
2E.1a Example 1 - Objectives 56
2E.1b Example 2 - Objectives 57
2E.2 Application Structure (Architecture) diagram 58
2E.2a Example 3 - Structure diagram 58
2E.2a Example 4 - Structure diagram 59
2E.3 Explanation 59
2E.3a Example 5 - Explanations 59
2E.4Specific challenges & solution – explanations 60
2E.4a Example 6- Specific challenges & solution – explanations 60
2E.5 Functions used (explanations in a separate sheet) 61
2E.5a Example 7 - Functions used 61
2F. Opening Macro 62
2F.1 Example opening macro code: 62
2G. Things to Avoid and Rules to follow 63
2G.1 Do’s 63
2G.2 Don’t 65
12H Typical use – 66
12H.1 Sub-ledger 66
12H.1a M/End analysis 66
12H.1b Rolling Recons 66
12H.1c Worksheet = Page Technique 66Pushing Excel

Citation preview

Pushing Excel Application Design

Pushing Excel – VLOOKUP() by Cliff Beacham Copyright © Cliff Beacham 2019. All rights reserved. Printed in the United States of America. Published by Cliff Beacham Inc., 4621 E Colorado St, Long Beach, CA 90814. This book may also be purchased for educational, business, or sales promotional use. Online editions are also available for most titles in the series. Editor: Cliff Beacham Production Editor: Cliff Beacham Copyeditor: Cliff Beacham Proofreader: Cliff Beacham Cover Designer: Cliff Beacham Interior Designer: Cliff Beacham Illustrators: Cliff Beacham Printing History: March 2019: First Edition. Trademarks: Many of

the

cliffcpa.com designations used by manufacturers and sellers to distinguish their products are claimed as

Pushing Excel Application Design by Cliff Beacham CPA, MBA, MCDBA This book examines the topics of Application Design, it discusses and pushes Excel’s boundaries by adapting it to various scenarios and how to extend the designed use of Excel features.

Published by Amazon Kindle

About the Author Cliff Beacham has spent many years working with spreadsheets from the days of Visicalc, through Lotus 123 and finally Microsoft® Excel. His career as an accountant started with being at first a Chartered Accountant and then a CPA. In addition he holds an MCDBA (Microsoft Database Administrator) qualification. This indicates his emphasis on data and information. His book entitled “SQL – A simple introduction by Cliff” is selling on Amazon. However, he is mostly focused on solving accounting problems and uses Excel as his chosen tool. In this book he shares his experience and knowledge (with many practical examples) – it aims to change the way the reader sees Excel – he counters some of the negative views of spreadsheets and discusses the many advantages – as Cliff is inclined to say – at the end of the book – “Is your life now changed?” Cliff claims that if a reader reads and understands this book, their knowledge and ability with Excel will grow to the level of expert.

Pushing Excel Application Design Table of Contents 2A. General

2A.1 Excel can be used as: 2A.1a Be Careful What You Wish For! 2A.2 Applications Facit Calculator (circa 1944) 2A.2a Development goes in cycles 2A.3 UI Design Objectives 2A.4 Change Control

3

6 6 8 8 13 14 15

2B. Structural Design Framework

16

2C Interface - Menus + Other User Interfaces

32

2D Internal control system

44

2B.1 Framework 2B.2 Implement process and design methods 2B.3 Objectives 2B.4 User needs 2B.5 Key variables standing data 2B.6 Modules & steps (minimize number) 2B.7 Example of Design specs 2C.1 Intuitive 2C.2 Logical 2C.3 Dropdowns List Technique 2C.4 Output – Reports 2C.5 Presentation and Format 2C.6 Navigation 2C.6a Aids to Navigation

2D.1 Dangerous current trends 2D.2 A 2020 operational paradox 2D.3 Totals 2D.3a Example: Total for a SUMIFS() Summary 2D.3b Example in action: Balance should be zero 2D.4 Agreement - Source & Destination 2D.4a Round-tripping 2D.4b Common key 2D.5 Reviews 2D.5a Review Summary 2D.5b Review Comparison to Expected Results

18 20 22 24 25 27 31 32 32 33 34 35 37 39

44 45 47 47 49 50 50 50 51 51 51

2D.5c Review Trends 2D.5d Review Accuracy of Calculations 2D.5e Review - Audit Area

51 51 51

2E. Documentation

55

2F. Opening Macro

62

2G. Things to Avoid and Rules to follow

63

12H Typical use –

66

2E.1 Objectives 2E.1a Example 1 - Objectives 2E.1b Example 2 - Objectives 2E.2 Application Structure (Architecture) diagram 2E.2a Example 3 - Structure diagram 2E.2a Example 4 - Structure diagram 2E.3 Explanation 2E.3a Example 5 - Explanations 2E.4 Specific challenges & solution – explanations 2E.4a Example 6- Specific challenges & solution – explanations 2E.5 Functions used (explanations in a separate sheet) 2E.5a Example 7 - Functions used 2F.1 Example opening macro code: 2G.1 Do’s 2G.2 Don’t

12H.1 Sub-ledger 12H.1a M/End analysis 12H.1b Rolling Recons 12H.1c Worksheet = Page Technique

56 56 57 58 58 59 59 59 60 60 61 61 62 63 65

66 66 66 66

Pushing Excel

2A. General If you do not have time to do it properly, how are you going to find the time to fix it? Note: I have said this before and will say it again and again! In general, application design is common sense but there seems to be nothing common about sense! This is not rocket science – it has been said 1000x. If you do not invest the time at the beginning, you will regret it later – and the later you leave it, the more difficult and time-consuming it will be to fix it. Often I recommend to my clients that we should start over – this time properly – they do NOT like to hear that – wanting a quick-fix – which is the approach they used in the beginning! This chapter tackles the topic of design – which can be considered a thought process rather than a methodology. It is quite dangerous to restrict our thinking by imposing any rigidity of methodology so please read this chapter in the spirit in which it was written. It is a bunch of things to think about – but it is your application – your creation and your design. Creativity is required to develop applications and Excel does a wonderful job of providing some great tools without restricting the developer more than necessary for the type of application that can be developed. So this is not a recipe to follow but rather a number of suggestions and points for a developer to consider when designing an Excel application. There is/are •

certain common threads and ideas that flow through most applications.

•

a databank of good practice

•

a workable approach – a solution that has some universal applicability. 3

Application Design We will explore some of these ideas and hopefully you will be able to add your own to them to form your own individual style. Firstly, do not expect a recipe for an application nor a methodology. It is a matter for judgment. The application does the job in the circumstances or it does not. It is easy to use or it is not. It is effective or not, efficient or not and it can be said to be a ‘good’ application or not. In the end there are some suggestions I will make and some caveats that I warn against but, in the end, it is up to the developer – who will do it their way. Many people use a spreadsheet as a ‘clever’ typewriter. They type the input into the output and mix input values with workings – hard coding values in formulas. Then they have the gall to label the result as “Spreadsheet Chaos or Hell,” conveniently ignoring the fact that it is of their own making; not Excel’s. By now – if you have read this far – you know that Excel basically consists of: • • •

a data store (using XML) a program that updates the data store an interface

all of which comprises of a number of worksheets in a workbook. Of course, there can be more than that (Charts, VBE, Add-ins etc but you get the idea). There are three application tracks to developing: 1. Users – the interface 2. Developers – the calculations and business logic 3. Storage – Data storage has to be optimally designed and managed. Each of these tracks require careful consideration and none are complete by themselves. The integration of these layers is what makes an application efficient and effective.

4

Pushing Excel Excel is a tool-application that can be adapted – it has been postulated that it is so flexible that its use is limited only by the imagination of the user/developer. So my last point, at the beginning of this chapter, is: Do it your way. In this book I am not trying to tell you how to do it; I am giving you suggestions that you might want to consider and providing some alternatives and possibilities for you which may be outside what you are used to. In the end you own the responsibility (and the authority) for development of your application. As a last introductory thought regarding methodology – never say never and never say always. The magic trick is to be appropriate – you don’t usually kill a cockroach with a sledgehammer – you don’t use all the tips and techniques described in this book all the time, in every application.

5

Application Design

2A.1 Excel can be used as: 1. a ‘quicky’ solution to an immediate problem – provides instant gratification. 2. An intermediate fix while considering a long-term solution 3. A proto-typing tool for a longer term application 4. A long-term solution as a developed application 5. A container for a sophisticated application that uses the Excel engine but looks nothing like Excel in the end product (you may not even know it is Excel). You will see that the above list starts with the simple and progresses down to the ultimate professional programmed application. While it is certainly NOT essential to even read this chapter, the more you progress down the above list the more this chapter is appropriate.

Excel is the KILLER APP The spreadsheet is the business app, word is the personal app and Office is the suite that forms the ‘raison-d’etre’ of the PC.

2A.1a Be Careful What You Wish For! Before proceeding further, a word of caution. There are a few very important things to consider before developing an Excel application to solve a problem or provide an accounting solution. Number 1 Caveat: Can a following consultant read your code? You write it but someone else has to be able to read it Number 2 Caveat: You will have to deal with the maintenance of: Hardware Operating system Environment System (ERP?) Customizations 6

Pushing Excel Remember – you break it, you fix it! Number 3 Caveat: Any advantage has a cost Advantage of customization is offset by the duty to maintain. Microsoft is addressing this in Excel – legacy stuff still has to work. Example: LOOKUP() is a legacy function that still works even though it has been replaced by VLLOOKUP() and HLOOKUP() – and also, recently, XLOOKUP().

7

Application Design

2A.2 Applications There is probably no more important topic than Application Design. Without attention to the architecture the subsequent build/development will be piecemeal and end up a mess. The power of Excel could be that you can do almost anything; the weakness of Excel could be that it allows you to do almost anything. Excel’s power then can become its weakness. What did we do before the days of the spreadsheet? This is a situation that many people forget. We used paper and we covered great schedules in manual calculations. Spreadsheets came into being at about (roughly) the same time as the electronic calculator. The mechanical adding machines (remember the Facit calculator etc) were first to arrive then we got the electronic machines that made the mechanical ones obsolete.

Facit Calculator (circa 1944)

When we processed data it was a manual process. General Ledgers were bound books. The Profit and Loss account was an actual account in the general ledger that was used to close out the income, cost and expense accounts so that the net profit was the remainder and transferred to the retained income general ledger account (after dividends). One of the audit tasks in those days was to check the 8

Pushing Excel general ledger calculations that had been done manually. The process was audited by tests and recalculations. Once volumes grew beyond what was feasible to recalculate then audit techniques changed to inspecting the system to ensure its integrity and testing. The amount of substantive tests could be reduced if the internal controls were effective. An Excel application is no different in principle from the old paperbased ledger-sheet models. Those models were applications (before we called them apps) and auditors did their job that involved: • checking calculations • adding totals • agreeing balances • substantive testing of items to arrive at their audit opinion. There has been no real change in audit objectives – only that we now have electronic aids to do the same thing as we used to do with paper models. GIGO existed in those days (we just did not call it GIGO). What has changed is that we have to deal with volume – the quantity of data has grown huge – we use sampling instead of ticking all the items; We use statistics to obtain a pre-defined level of confidence that populations are represented by our sample within a defined precision limit. Audits included assessing internal control effectiveness and on the basis of the results set the level of substantive testing of the underlying data.

9

Application Design Techniques of: • tracing • totaling • agreeing • balancing • recalculation • review for testing the: - completeness - accuracy - reasonableness - whether it equals output - sanity - review for unusual items are still used to provide assurance of: o integrity, o reliability and o matching of the accounting system whether it be in an Excel spreadsheet application or not. We again come full circle to stating that Excel is just the tool that is used to do the job. When using a spreadsheet, one type of risk is addressed by the skill and professional abilities of the client’s staff (user). Possibly there may have been a dumbing down of staff - now that computers have taken over the processing. These days, the reliability of a system is now assumed, totals always agree and input always equals output but when considering Excel with its flexibility this has to be redone each time because of the nature of the tool. However, assessment of any internal control system has to be performed in each audit to establish that the system is still functioning effectively. We still assess audit risks – probably more nowadays than in those days but the process of assessing the system still remains.

10

Pushing Excel However, auditors do not like having to extend their tests and Excel is so pliable that there is an added risk attached to a system that can be altered – but in the ‘paper days’ it was the same - and systems could also be changed easily. My comment to auditors is – deal with it. Management letters are there for recommendation covering internal controls and SOX has established a new set of standards (section 404). Possibly the issue is one of audit budget - which tends to go to the lowest bidder although it is not PC to say so. There are two basic types of Excel applications (apart from Add-ins to Excel which are outside the scope of this book). 1. Simple Ad-hoc spreadsheet No security requirements, no Macros, usually cluttered and may be hard to use, not robust, does not provide assistance to the user, no rules, conventions or structured development. End-users maintain the workbooks themselves. 2. Complex, self-automated spreadsheet Developed using conventions, rules and follows professional standards. Stand-alone applications. Can contain some VBA but only at a basic level. Typically, an Excel application is developed by an Excel ‘expert’ who works for the company and then leaves. They may try to hand off the application to someone else but that can have varying degrees of success. It is common that most applications are developed piecemeal with little documentation or guidance for a subsequent user. Applications may not contain sufficient documentation and are not normally developed according to any standards. This results in the application becoming unusable and it is commonplace that another consultant is called in to fix it. Since technology moves forward, developing constantly, changing the features and capabilities of Excel, it may be that new techniques are 11

Application Design available so the application gets updated or re-written. The application passes to the next iterative development loop and the process is repeated. One feasible solution is for development to follow some design principles - and that is where this book may help. Each different application will have its own opportunities and challenges. Most spreadsheets do not require planning or even a disciplined approach. However, as complexity increases so does the need for such a methodology. A consistent model has its advantages in efficiency, effectiveness and speed of development. Information will flow from the input to the storage area and on through the workings to the output but the planning process will probably go the other way – start with the end in mind and work backwards. The build can be done either way, depending on the situation. There are other challenges. One that springs to mind is the altering specification scenario. Features added before the model is finished. This could also be termed – feature creep. Also sometimes it is appropriate to go back to the beginning and start again from the position of learned knowledge from the project so far. It may be ironic that, frequently, by the time you have completed the project, you know how you should have started it.

12

Pushing Excel

2A.2a Development goes in cycles While an Excel project may not warrant the seeming big effort, nevertheless this diagram represents the processes that have to be followed even if it is a 1-man project

Project management To varying degrees every project should come under the management of a suitable authority Logistics Before development work begins the project should always be evaluated to seem to be feasible and worth doing. This decision is often made before a consultant arrives Webster defines logistics as the detailed coordination of a complex operation involving many people, facilities, or supplies. So the subject of logistics includes the gathering of resources and coordination of efforts by the various people involved, the scheduling and the planning activities. Development Outside expertise is often needed to do the development. However, consideration should be given to who in the organization is going to use it, update it, maintain it and take responsibility for it 13

Application Design Testing Usually bench-marks and trial data are used to test whether the application has achieved the stated goals. User education Training can only be done successfully if the trainees are suitable to the task. Usually they are already able to handle the subject matter and it is a matter of training them to use the tool. Review Once tested there is an ongoing review of the application. No application should be relied upon blindly. There should be a mechanism for checking the input is correct and the output is what is expected. If it is not, then the matter may have to be referred to the Project Manager again for correction if necessary.

2A.3 UI Design Objectives Excel provides a really rich environment for development of worksheet applications. There are many built-in features that can be exploited without resorting to VBA code and these should usually be used instead of trying to reinvent what is already there. There are a number of points that are worthy of consideration to aid you with the design of the User Interface; these include the following: 1.

KISS – keep it simple to follow the information flow Navigation

2.

Clarity - by not cluttering

3.

Consistent opening - Structure flow

4.

Consistent formatting

5.

Colors – compatible theme (EG not Yellow on Black)

6.

Borders, shading and totals (including grouping)

7.

Aim to be intuitively obvious

8.

Group type of area i.e. – input together, in one place

9.

Use colored TABS 14

Pushing Excel 10. Robust - Not error-prone 11. Document - Instructions and explanations 12. Conditional formatting adds a new dimension Note: this is just a checklist – each of them could be the topic of further discussion.

2A.4 Change Control 2A.4a Versions The most important reason to have version control is to be able to recover an earlier version of the project if you have encountered a significant problem. It is slightly different from back-ups – it involves a tracking mechanism like a version control number (or date) and an indication of the status of the application if possible. A technique I have found useful is to create a backup folder in the project parent-folder for storage of these versions. You can then revert to the previous version. I find that I do not use it very much but when I do I thank me stars for this facility. Example: This file: 04_PushingExcel-AppDesign_v3.docx

Notice that: The 1st 2 digits ‘04’ denote the place in the structure of the folder The 2nd group is the Book name The 3rd group is the Topic or Chapter The 4th group gives the version number Example 2 PushingExcel-All_Chapters_v24.docx

Example 3 28_ Database_TBals-ConsAFS_2014_cv75.xlsm

15

Application Design

Also I try not to delete any files so I have an archive folder for files I would otherwise have deleted – this is also useful occasionally. Am I being anal? Yes – but it has saved my butt a few times so I offer the technique here for your consideration. 2A.4b Documentation of changes Include changes to Objectives, Structure, Detailed Workings, History and Output. Too many times I hear – “Don’t bother” with documentation when it would actually have speeded development by simulating a structured development process. Of course, everything in moderation and to go overboard is not a good idea either. Documentation can be a huge time-waster but it is not a switch on or off – it is a continuum – an appropriate amount of documentation is very useful. Good programming never (yes, I said NEVER) starts with the developer sitting down at the computer and starting to write code. A diagram is a very powerful technique and if used properly Excel has great drawing tools available – and a picture is often worth a thousand words. Good documentation is often crucial to being able to understand an application. There are some amazingly complex applications out there and documentation will aid in continuity and less dependence on the developer after the developer has moved on (and even when they are still around it provides the developer themselves with a trail. Programmers write code - and (usually) would not even think of writing uncommented code.

2B. Structural Design Framework The design of an application is at least as important as any other aspects of application development. There are basically 3 aspects: a. Design = architecture of the application, including: 1. A diagram of workbooks, tables, ranges and sections dedicated to the application 2. A list of variables used (name ranges, tables and formulas) 16

Pushing Excel Note: There are many experts who endorse application architecture as THE most important aspects of design. Personally I feel that a client/server approach (as far as practical) is my preference. b. Techniques used in the application: 1. Pivot tables and other add-in applications 2. Reporting (Charts, 3. Developed techniques such as built-in Internals controls, round-tripping 4. UDF's (User Defined Functions) 5. Macros c. Formulas used/developed (these are never included as part of the Excel program suite) – they belong to the developer 1. Outer Nested functions 2. Inner nested functions 3. It is a good idea to document Formulas used as they will never be included in the Excel Help files or books on Excel. Of these, the first (design), is perhaps the most important of all and a developer should specifically include it as a part of their communication with future users and developers. There is probably no need for a 3rd intermediate layer/tier in the design but it could be considered

17

Application Design

2B.1 Framework This section provides a framework to be considered when developing an application. Many of the concepts have been ‘borrowed’ from programming techniques. Section 2 therefore follows the design methodology that is here for your consideration and you are sure to get some ideas that will aid in your application development. So take from this chapter what you will and make your own decisions after all you are the architect of your own apps. This section is all about structure. While there isn’t one architectural structure that would be universally applicable. However, there are certain considerations that would probably result in a better structure. A 'magic bullet of design is to try to keep all your DATA in one place and separate the input from the intermediate, workings and output. This is quite easy when considering the input data – pretty logical but it grows a bit fuzzy when looking at intermediate data. For example quarterly results should not be stored in the data area. There is a temptation to add a column every 3 months and calculate the quarterly total. This means you will not be able to copy formulas across and have them auto adjust to the relevant month. The correct way (in my opinion) is to have a 'quarterly’ area where you store the total of the 3 months making up the relevant quarters. 2B.1a Workbooks and Worksheets This is in the arena of physical design (within the Excel application). With an Excel application one of the most important decisions will be what Workbooks to use and how many Worksheets to use (design in). In my opinion you should try to avoid multiple Workbooks – keep it all in one Workbook (avoid external linking) but you can use as many Worksheets as you find convenient, in fact they are a great way to separate between sections of the application. Also I try to avoid using a worksheet for more than one purpose In addition to using Workbooks you might also consider using an Excel Table or a Named Range (see my book on Ranges, Tables and Data Storage for a discussion of these) 18

Pushing Excel During the design phase we will consider the following factors: 1. Objectives Enumerate (bullets, if possible, adds focus) 2. Time Scale for development Get a quick result to indicate progress 3. Complexity/Simplicity Reduce complexity by Divide and conquer Logical Data Flow from input to output 4. Ease of Development and Maintenance (encapsulation = 1 objective per area, keep it simple by divide and conquer) 5. Extendibility (or not) For future development (EG do we need a history section?) 6. Robustness Don’t hard-code variables into formulas 7. Deployment to other users/training Think that others will have to maintain the app 8. Internal controls Build-in controls from the start – it aids development 9. Security issues Add later – they detract from development 10. Backup and version control Even when in development there is always something you would not want to lose – so have a backup plan – which can double as a version control system as well. Navigation within your application should be intuitively obvious but this can be aided by Instructions and Diagrams much the same way as a complex website can have a site-map and an Instructions page. A menu and/or list of contents can be added to aid the user also. 19

Application Design

2B.2 Implement process and design methods 2B.2a Naming conventions Any structured data or lists can benefit from a naming convention, be they folders, files or variables. Hungarian notation (which uses the variable type as a prefix to the actual name) is not a good idea in Excel naming – the type of variable does not usually matter (and then only when writing macros in VBA). CamelCase uses Capitalization of words to make them more readable. The name camelCase refers to the convention of using internal capital letters (like a camels humps) to make text more readable. It is mainly used in programming SOAP and XML but it can (and should) be used if it adds to readability of variable names etc. Common examples are: iPhone, eBay. Pascal case is where every words is in proper case EG: PascalCase The underscore character can be used to separate words or groups to increase readability – this is sometimes referred to as snake_case. Using a hyphen between words is called kebab-case. Naming rules are a good technique when naming ranges that will form a series (and you can utilize the INDIRECT() function more easily. Use Bolding to increase readability. Use intuitively obvious names for ease of reference. For example, Price is an obvious description - PriceList is obvious for a list of prices. When thinking of naming rules the situation sometimes demands a series. Try to make the first part of the name a constant if you want them grouped together in the Namebox. Here are two examples: 1. the first is a series of Print named ranges – note they start with the underscore (to ensure they are listed at the top) and all have _Prt_ as the first part of the name so that they are grouped for ease of reference.

20

Pushing Excel 2. The second shows how a number of imported Trial Balances for various companies can be named so that they are listed in a logical order:

2B.2b KISS Of course, the KISS principle applies; we are here to make it simple, not complicated but this is just a reminder. Logical flow, structure and being intuitively obvious is good. It is sometimes difficult to think of a logically structured framework but my experience has been that it is worth the effort. So the KISS principle needs to be amended to involve a structured approach – chaos can result from a lack of organization. It is sometimes said that the advantage of Excel is that you can do anything – but that has to be also that it is a weakness of Excel that you can do anything – Excel does not guide you; you are left to do whatever you want. Many people refer to what they term Excel Hell or whatever name they think of but the truth is that it is entirely in the hands of the developer. Excel is NOT to blame, the responsibility lies with the developer. I have said this before and will again (and again). 21

Application Design 2B.2c Names Names should be appropriate for the application. Users and maintenance will be more accepting and will become familiar with names that are descriptive and ‘user-friendly.’

2B.3 Objectives While it seems obvious that you should always think of the application’s objectives before you start a project there are some things that you should consider about such objectives. Firstly there are short-term and long-term objectives. This is especially applicable when designing an application in Excel. For the short-term a ‘quick and dirty’ approach can get quick and dirty results and many clients will specify that they just want the job done with the least cost. This is a common response to questions about objectives. Clients often do not understand the significance of their answers and have to be reminded that a short-term solution can be hard to run, difficult to maintain and even dependent upon the developer, other users may find it impossible to follow or take over the use of the application. This happens a lot with Excel applications due to the nature of Excel itself as a tool and not a solution. The answers to the developer’s questions can have an impact on the design, structure and longevity. Be careful what you wish for, you might get it. Excel is a great prototyping tool and it is very powerful and flexible but it only as good as the people who are developing the final application. It has been said that – It’s strength is that you can do anything with Excel. It’s weakness is that you can do anything with Excel Applications may not contain sufficient documentation and are not normally developed according to any standards.

22

Pushing Excel So part of thinking about objectives is the question – are we serious? ‘Quickfixes’ may not be able to be extended. For example, without a history section you will not be able to produce trend reports. In quickfixes, amounts/values can be hard-coded instead of in a control section. Updating may be difficult. Example of Objectives: Objective (requirements) Establish a Database that can be used for reporting and projecting -

Should have the capability to report Actual-to-date and Budget from then on

-

Should be capable of reporting monthly, Quarterly & Annually

Storage History - initially for 3 years Reports (Output) Current year Prior year Next year Example; One of the most common objectives of an app is to convert data into information. Such an app might have the following structure: • • • • • •

Source data as imported Initial conversion Workings Parameters Intermediate output/info/long-term information storage Presentation reports

23

Application Design

2B.4 User needs User needs are of paramount importance; they are the reason for the application in the first place. When assessing needs, there are many roles that a user can fall into: 1. 2. 3. 4. 5.

Data entry Changes in parameters and metrics Update maintenance Developers Users of the output from the application

The first two might be ‘normal’ people but the 3rd and 4th will require some understanding of what is happening in the application. The fifth covers and interacts with the objectives of the application. 2B.4a Data Entry User Data entry should be designed for ease and verifiability of input. While it should require as little expertise as possible in order to minimize any dependence on expertise it should be capable of training a user. Data entry can be divided into: 1. a user that does not have expertise because it just involves typing in data. 2. the second could involve importing data which may involve some much more sophisticated methods such as parsing. However, such methods can usually be taught without problems. There are no hard rules – the developer should have some levels of training in mind and requirements for each function. When developing a complex application it is often not possible to train a beginner-level to perform what is needed to implement the application. The most that can be hoped for is that the developer takes the ease of performing the various functions into account and ‘KISS’ as much as possible. In the same way as development should always be aiming at ‘compatibility with the oldest version of Excel’ that is in use. For example IFERROR() is an Excel 2007 function and will not work in Excel 2003. Therefore IF(ISERROR()) should be used until no one is likely to 24

Pushing Excel open the application in Excel 2003 and find that the function does not work. Number 2, 3 and 4 types of users might well be grouped into one category because their needs overlap a lot. 2B.4b Developers, Maintainers and Updaters Ease, ease and Ease. The structure should aid the functions of updating and maintaining the application. Therefore areas that are reserved specially for aiding these users. •

Parameters should be grouped in one place.

•

Updating should follow a standard procedure that enables verification and tracing back to the original source.

•

Development should have a section where the path followed is recorded and the reasons behind design are expressed.

2B.4c Output (Users of the output only) While it is easy to relate to the production of reports, it is also easy to skip over other types of output. These might include: 1. Graphical expression and presentations 2. Add-in like Pivot Tables 3. Different types of reports (including customizable) 4. Input to another application 5. Ad-hoc queries

2B.5 Key Variables - Standing Data Most applications have some standing data. This is the basis for the assumptions used in the applications. For example, Price of a product. This is an assumption – that this is the price used in the application. It can be changed and, if changed it makes sense for it to be changed in one place and not in various places that may not be easily determined. A concept that could be considered is what database people will term atomicity. This means breaking down the amorphousness of information into its components. An example would be Sales. Now it 25

Application Design may will be appropriate to just look at the totals sales revenue and it may indeed be difficult (or impossible) to break down sales into products and prices but, on the other hand, maybe it would be advantageous to use Number-of-Units times Price. Then you could change the price and watch the effects flow through the application. My point is that if you are going to break down into the components do not put Price in more than one place. Use an ‘assumptions’ area and define a variable Price and then use the variable called Price in as many places as you want. Experience teaches that it is best to define these variables all in one place. 2B.5a Parameters, Metrics KPI’s and Dashboards So if you accept that whenever a value may be altered, it is efficient to make the entry in a place dedicated to the entry of similar information. Another way to say this is: Application inputs should be as parametric as possible. Some definitions would seem appropriate here: (i)

Parameters

A parameter is an input of a variable that may change but It can be an assumption or some input used in calculations Examples include: Tax rate, Growth rate assumed (ii) Metrics These are output - result measurements, such as growth rates achieved. They are used to track progress towards a particular goal. BTW: They can be input if calculated or obtained elsewhere. (iii) KPIs These are the output - specific Matrices tracked and compared with targeted objectives (iv) Dashboards These are the output - reports (often in graphic form) that illustrate targets, results and progress 26

Pushing Excel

2B.6 Modules & steps (minimize number) It is logical that a planned structure will aid understanding of the application. Although not a rigid requirement, an application can usually be divided into logical tiers: 1. User Interface tier –encompasses both input and output 2. Business logic tier 3. Data storage tier The design should take into consideration the flow of information, starting from the input through to the output. However, it not that simple! For example input is in various forms. 1. Standing (or Control) data 2. History (from a storage area) 3. Both of these have had to be input before and now form an internal source of data 4. Current data that is either manually input or has some method of automatically importing the current data. Large amounts of current data can be: a.

Pasted into a receiving area

b.

Fetched by a VBA routine

c.

A text source file, opened and parsed in Excel

d.

Linked to an external source (that can be Excel or another such as the result of a query)

So we could say – Paste, Fetch, Parse or Link. An Excel application can borrow from this design. Manually input data should be either typed or pasted into an area designed for input only. Input should almost never be input into the output. When beginners develop applications using that method it may well result in chaos. The same can be said for hard-coded data in a formula. The update of such data will require finding it first and they can be hidden. So, except for trivial applications, never do that. 27

Application Design Named Ranges and/or Excel tables can do a lot to aid in structure, control and navigation. As you get used to using them you will become an adherent to this method of referencing designated areas. In the meantime the user sees an interface. It is up to the developer to ensure that the user has an effective and easy-to-use application 2B.6a Input = the interface with the user This is not the same as being updated or maintained although these aspects should be considered (they are also very important but to a different level of user). The first layer of input is the user – who will use the application (rather like an automobile where the driver does not have to know how it works in order to drive. 2B.6b Ease An input area should be designed for ease of input. This may consider how data is input 1. is it a cut & paste method or 2. is it a type it in method. 3. perhaps the data is imported by some programmatic means – just 1xClk a button and hey-presto the data appears. An example of this is an application that the author developed where a button fires a macro. The macro contains VBA code which uses ADO (Active-X Data Objects) to interface with a SQL Server database and bring back the results of a Stored Procedure. As far as the user is concerned they just 1xClk the button – not knowing (or caring) how it happens). 2B.6c Verifiable (Complete and accurate) Once data is input by the user, it should have some means of checking that the input is correct and accurate. This may involve calculating a total (or >1 total). Accountants use the term Balance, in this case meaning to ‘agree with another control amount.’ This is only a part of an internal control system but if the input is wrong then GIGO applies.

28

Pushing Excel 2B.6d Workings separate Business logic can be built into links and there is no reason not to do this if it is appropriate. However, a developer should certainly consider whether logic would be better separated from the links. An example is a summary link such as SUMIFS() – the summary calculation is built in and it is appropriate to do so. A controversial situation has been whether to calculate the monthly transaction’s amount by deducting one column from another. EG: deduct May trial balance from June trial balance to calculate June transactions. For example, take this situation: Example 1:

You can calculate the monthly rent by using a helper column like this: Example 2:

Or you could perform the calculation during the link to a trend report – resulting in this: Example 3:

29

Application Design My choice might be the second method perhaps because I want to keep the input as pure as I can. However, there is no clear answer – only factors to consider. My decision would be based upon the consistency of the columns – example 3 has consistent columns and so does example 1. While in example 2 the columns are mixed. 2B.6e History Applications often include some history – data that has been input over a period of time in different periods. It provides the basis for trend analysis and comparisons with past periods. When designing a history section dedicate a worksheet to storing only the data. This follows the logic of 2B.6d above. Try not to put anything at the bottom of the worksheet – then you can use defined ranges that include long/tall sections without fear of overwriting data. As usual there are exceptions to this rule. However, there are times that you might want to have a sub section to hold a summary – place this above the raw data because you will never be entering additional data – unless you add rows to the summary. Summaries often follow the same pattern as the data (EG: Monthly data) and the columns will therefore follow the same headings.

30

Pushing Excel

2B.7 Example of Design specs There will be a separate Workbook for each entity These will be used as source for a consolidated Workbook that will combine for the Group Input

YTD-T/Bals in Separate worksheets

Working

Monthly Income Stat, Cash Flow calcs

Storage

PY (Prior Year), Budgets

Output

BS, IS, CF

Storage: A separate area will contain history 1. Actual YTD

Will be imported after finalization of consolidated accounts

2. Budget

Manual input area

3. Prior year

Will be for the 'same period' last year

YTD will be used as source from the ERP system so any changes in the ERP will reflect in the current period no matter what period it was entered after the close T/Bals will be kept at the bottom of the Working Sheet so that expansion is dealt with - minimizing inserted rows A common COA will be established in the Group T/Bal range Note: While you might not follow exactly what each of these comments are referring to, nevertheless, you should get the idea of what type of item is being described.

31

Application Design

2C Interface - Menus + Other User Interfaces 2C.1 Intuitive Perhaps it is one of those ‘Universal truths’ that applications are better when they are intuitively obvious (rather than confusing). There seems to be no standard way or guidance on this other than to state this. Piecemeal development can result in a confusing layout. Users usually have to work out for themselves how the application works. The days of user’s manuals are gone in an age where paper is seen as a thing of the past. Without getting into a ‘paperless or not’ discussion it is obvious that an application should be as intuitive as possible. Because Excel’s default is to open at the last place it was closed it may be a good idea to have an opening macro that opens the application at an opening screen/window.

2C.2 Logical ‘Start at the beginning and go on to the end’ says the Queen in Alice in Wonderland (or Excel in Wonderland). Whatever you do it should be logical and follow a flow. Structure is virtually always good. Across then down is the standard for the English language and so Excel follows this format. By careful when deciding what should be in columns and what should be in rows. If a list is to be extended, it is better that the information be extended by adding rows. However, when using dates (months) it may be better to add a column. For example, a Trial Balance should be GL Accounts in rows and the balance in a column.

32

Pushing Excel

2C.3 Dropdowns List Technique A dropdown menu is a good technique to aid navigation. Here is an example:

Behind the dropdown there is a macro that will take the user to the Range named in the dropdown list. This can also be a handy selection technique for reports. Here is the code for the macro: Sub ChooseCo_Case() Dim Choice As Integer Initialize Choice variable Choice = Range("z_CoChoice").Value Select Case Choice Case 1 'AMM Worksheets("TBs").Activate Worksheets("TBs").Range("TBal_AMM_2014_12").Select Case 2 'PCCM Worksheets("TBs").Activate Worksheets("TBs").Range("TBal_PCCM_2014_12").Select Etc Worksheets("TBs").Range("TBal_AMP_2014_12").Select Case 16 'APS Worksheets("TBs").Activate Worksheets("TBs").Range("TBal_APS_2014_12").Select Case Else Worksheets("TBs").Activate Worksheets("TBs").Range("TBal_AMM_2014_12").Select End Select End Sub 33

Application Design

2C.4 Output – Reports Reports can be named as ranges. In this way you will get consistent selection and can have more than the default Print Area.

34

Pushing Excel

2C.5 Presentation and Format Formatting can be a sore point with clients who do not want you (perhaps a consultant) spending time on cosmetics and making your reports look ‘pretty.’ However, you will be judged on the output despite what they say, so pay attention to your formatting both in the application and in output reports and your work will look professional. Credibility is often dependent on the look of the report. An untidy mess does not have much credibility. It does not take a lot of time to make your masterpiece look professional and it actually helps with the usability of the app if it looks clean, clear and consistent. Therefore, make your application look professional and consider, at least, the following: a. Be consistent – do not mix formats b. Numbers – Right justified (Don’t center numbers) c. Use Format Painter (on the Home TAB) d. Learn to customize formats e. Size – for print or internet? f.

Don’t overuse $ format for currency – just 1st and total

g. Be Clear – uncluttered h. Use appropriate fonts (sans serif for numbers, and headings) i.

Use white space

j.

Use Colored TABS

k. Try to minimize the number of functional areas per worksheet preferably have only 1 (but . . . ) l.

Use colors judiciously and appropriately (eg never use Yellow on Black)

m. Be logical (eg Order) n. Follow a flow pattern (especially Down & Across) – think about what should be in Columns vs Rows

35

Application Design o. Avoid merging cells (Use ‘center across selection’) p. Do not over-format q. Remember what you are formatting: print formatting follows a different philosophy than screen formatting On a screen, a dark background looks good – but don’t use it on reports to be printed r.

Decide whether you are going to print in color or not and use colors appropriately

s. Do not use very large fonts t.

Learn custom formats

Excel worksheets provide excellent presentation of output in the form of Reports and Charts. Even Diagrams can be used in output presentations. The type of output and type of charts used are as much an art as a science and the developer has to ensure that they are getting the correct message across to the reportee.

36

Pushing Excel

2C.6 Navigation While is may seem obvious that a user has to navigate around the application, it should be borne in mind that Excel can hold 256 Worksheets, each with around 1 million rows of 16 thousand columns of data and information. Converting data into information may well be what you are doing. Perhaps a formal database is a better solution but Excel is a great prototyping tool and will handle a lot. To start, I recommend an opening screen then a List of Contents with hot links to the sections. Maintenance is a higher level of skill and whoever will perform the maintenance will probably be able to navigate the application. However, a central navigation screen can make life easier. Maintenance includes updating. Users get the reports out – they may put the data in. As the application grows in complexity, the required skill-level increases. Skill level needed vs Complexity

Note: The relationship is not necessarily linear – this is just an illustration. 37

Application Design I have had a client say to me “Don’t make it so complex that a ‘normal’ user cannot use it. The answer is that a complex application can only be simplified to a limited extent and the skill needed is tied to the type of user. You might divide users into 3 types: 1. User 2. Updater/Maintainer 3. Developer However, the boundaries between the types is fuzzy. A developer has the responsibility to ensure that the is application useable by the user and updatable by the updater. Often the aim is a compromise between dumbing down the app to a level that the user can handle and the level that it needs to be to get the job done. Users will have to be trained or educated to whatever level is needed. It may well not be possible to use simple formulas and functions and the prime objective is to ensure that the application will do the job. However, users will need to be able to use the application. They may need training and therefore they have to also be willing and able to be so. It can be a challenge to find staff to handle a complex application and is amazing how few people are willing to learn. An added caveat – suitable staff would have to be located into the future and there may not be continuity of retraining. In the same way as bookkeepers cannot be expected to do the job of an accountant, a level 1 employee cannot be expected to perform at level 2. It seems that the general attitude towards Excel is that if you understand VLOOKUP() and Pivot Tables that makes you an expert. That is why this book aims to extend the perception to the point where Excel is understood to be what it is – with all the power and abilities that can be used to perform some really advanced stuff. There is a shortage of expertise and there are no laid down levels of expertise. The author of this book (me) claims an expertise level of about 6 on a scale of 10 – that may give you some idea of what I am talking about. It has always amazed me that many managers think that 38

Pushing Excel all you need is knowledge of Excel to solve complex accounting projects. Excel is a tool – a great tool – but you need subject area knowledge to exploit the capabilities of the tool. Just like a carpenter can use tools to create furniture but you have to be a carpenter not just able to use the tools. Navigation techniques can minimize the impact on users who are only qualified at the basic user level. However, they can also make life easier and the use faster - for all levels of user.

2C.6a Aids to Navigation TABS Tabs can be colored and named. Naming should be in a logical order and be named logically. Groups of tabs can have the same color. I always have a tab that I name Instructions (colored Yellow) but that is a personal preference. If you RtCtk (Right Click) the navigation bar at the bottom left of the Worksheet tabs (like this): Navigation Bar

you get a vertical list of worksheets and if there are too many for the size of the list then this box (note the thumb) will appear:

39

Application Design

40

Pushing Excel MENU Menus can be created in Excel options

Here is the New Tab on the Ribbon

41

Application Design CONTENTS A list of contents is useful for the following: 1.

An overview of the application – which would be enhanced by a diagram reflecting the structure of the application.

2. If the contents have hot-links it will aid navigation 3. Providing a starting place – it can be the target of an opening macro and contain extra features eg: the user who last updated the app. Example of Contents and TABS

42

Pushing Excel NAMED RANGES As described in Chapter 2, named ranges can provide the destinations for links or access via the drop-down name box. Example of Contents using Range Names and live Links Note the Range Names in the dropdown

A user can either choose the Range name from the dropdown list Or 1xClk on the live Link to the named range

43

Application Design

2D

Internal control system If you are not under control you are out of control.

So it is with an Excel application. Without internal controls there can be no assurances that the results are what you require. Internal control aims at maintaining the integrity of the data. Mostly, this means the completeness and accuracy. It may include totals, agreement between input and output or whether calculations are performed correctly. There are some techniques that can be used to ensure these and become very important if the application has to be audited. One crucial technique is to maintain an internal audit sheet that can be easily verified. For example, if accuracy is important (and it mostly is) then to compare a total of the input with a total of the output has a high probability of verifying that the internal workings have not omitted any amount.

2D.1 Dangerous current trends Consider some current trends – some of which are quite unfavorable: 1.

We can no longer afford to do it right – there are the dangers of that – do our best with the resources available

2.

Good enough is the new norm/standard

3.

Symptom of incompetence or ‘get the job done’

4.

Different standards/objectives

5.

Materiality leads to good enough

6.

Need to be excellent not perfect

7.

Perfection = we aim at perfection but we should not get too anal.

44

Pushing Excel

2D.2 A 2020 operational paradox If you have the time, skill and resources you should aim at doing it right But if you lack any of those resources you have to make do with what you have. Accounting has always been a ‘do it right’ ‘balance to the cent’ EG: Trial Balance = 0 Balance = agree

The relevant required precision = 0. This means it has to be done right! There is the famous compensating error that has a low probability, however this is offset by even in a situation of low probability, there may be high impact items. This is why we insure against the risk by: Insurance >> competent qualified staff, (auditors ask) – CPA’s on staff? License should mean something – now we have emerging trends: – just do it – I don’t care about standards – and the most important:

Survival mode forces compromise - no general standards without motivation to do it right. - Only worry about the tax effects. - Cash flow is king (a typical short-term view). - Trend towards off-BS finance. The Balance Sheet has been re-defined overseas as a Statement of Financial Position rather than just an accounting mechanism. The US has rejected this title; maybe because it is too difficult to implement. Auditors have been known as the watchdogs of society – without them we are just playing with numbers 45

Application Design Is it true that historical cost = hysterical cost (down the road) because the cost many years ago means nothing today and is therefore irrelevant. For example, if you bought a house in 1970 for $20,000, is that figure relevant in 2020 when the current market value is $700,000? Financial Statements can only be relied upon if they represent the financial position and/or the results of operations! These concepts apply to Excel reports and applications as much as Financial Statements. An application can be relied upon only if the interval structure is sound, the workings are consistent and the reported output is reliable and in concert with both the input data and the design of the application in accordance with the parameters as expressed.

46

Pushing Excel

2D.3 Totals The most obvious technique is to agree a total to some other total that should be the same amount. While this cannot guarantee correctness we could compare input with output or a balance to ensure completeness and/or accuracy.

2D.3a Example: Total for a SUMIFS() Summary An example can be a simple SUMIFS() analysis. Total the data before the analysis and then the total of the analyzed data and agree the two totals to provide evidence of a complete analysis. The method is not foolproof since there can be the nefarious compensation error. A technique I have used is to code every data entry with a common code that you know is not included in the analysis. For example XYZ and then code the entries. The XYZ total should decrease to zero when you have finished and all the entries are coded. Step 1: Start by coding the source with XYZ like this – note the destination analysis shows ALL the items as coded XYZ

47

Application Design Step 2: Code the source (leaving out some of the entries) – you will see the balance for XYZ decreasing.

Step 3: Once all the items have been coded, the XYZ total = 0.

Now you know the analysis is complete. If you have not coded an item, there will still be an amount in the XYZ category. In an extensive list of input data a technique could be to use ‘Misc’ instead of XYZ – a small balance can be insignificant and ignored. Conditional formatting can be used to format cells that do not ‘balance’ whether in an internal control area or throughout the workings. This can draw attention to the imbalance easily since, within a spreadsheet full of data an error can occur without being noticed.

48

Pushing Excel

2D.3b Example in action: Balance should be zero Traditionally, a Balance Sheet should balance Debits and Credits to zero. Also a DR/(CR) trial balance should balance to zero. If a cell’s value is not 0, format the cell Pink. Realistically because of rounding errors a small range (EG: between 0.01 and - 0.01) is preferable to a = 0. Here is an Edit Formatting Rule screen:

49

Application Design

2D.4 Agreement - Source & Destination 2D.4a Round-tripping Excel does not push data – it pulls data by referencing in a formula. For example, SUMIFS() and VLOOKUP() pull information from the source to the destination. To ensure completeness and trace errors I will often ‘Round-trip’ with an existence check (see VLOOKUP() on the 1st column) to bring back a confirmation when setting up such a mechanism. Any missing data items will have an N/A error (or whatever you have specified).

2D.4b Common key One of the basic tenets of internal control is to be able to trace to the source and supporting information. Many applications provide drilldown facilities and/or data source connections. Debugging is aided by this as is also reconciliation between two sets of data. There has to be a common key in order to provide a link. Some connections may only be a date but a reference is preferable. However, if data is 'posted' without a trace-back key it will be difficult to confirm the destination data with supporting data. An audit trail can be a powerful feature. This is not confined to Excel applications - imagine trying to reconcile a bank account with no method of connection (no common key). A common key can enable automation (EG a check number) and takes the guesswork out of the exercise.

50

Pushing Excel

2D.5 Reviews 2D.5a Review Summary Summaries can have an internal control aspect. A user may be able to review the summary and discern if all is well - or not. While this may not be a part of the formal system it is often a very good indicator – most of the time a user has some idea of what results are expected and if the ball-park is not right then a red flag goes up.

2D.5b Review Comparison to Expected Results Auditors often are given the instruction “examine for usual items.” While no hard and fast guides are expressed it is sometime obvious that a result is wrong – such situations include: -

Debit where a Credit (or Negative where Positive) is expected

-

Ball park total does not look right

-

Common sense look (sanity check)

2D.5c Review Trends -

Graphical representation/charts as aids to review

2D.5d Review Accuracy of Calculations -

Balancing - (Agreeing) with a total or other information

-

Compare In with Out

2D.5e Review - Audit Area An application can include an area specifically for Internal Audit totals and also it can include techniques that aid debugging. Some applications can be sensitive to new information not being as accurate as desired. This may be because of changes in the structure or composition of the source data. Another common course of inaccuracies is in coding changes between periods. Just because a trial balance flows accurately through your application does not mean that next month will be the same. New 51

Application Design accounts get opened; sometimes there are inconsistencies in coding – this month we put it to Misc, last month it was Other Expenses. OK enough of the causes – It is a good idea to balance each and every step of the way. Also build a total at the beginning of the process and see if the total at the end is the same. Example: Internal control area - Balance Sheet category totals Here is an example of an internal control area that provides assurance that the Balance Sheet category totals are correct at 3 different stages of an application. It also provides an indication of where the calculation path goes wrong since the beginning of the chain may be in balance but not later on in the process so it acts as a debugging tool as well.

52

Pushing Excel Example: Trial Balance is in balance each month Here is an example of an internal audit area that provides assurance that the trial balance for each company for the month of 201407 is in balance. It shows the trial balance for the company MMG out of balance by $1.00 with a conditional formatting formula that turns the cell background to pink if the condition is true (out of balance) to draw attention to the error condition.

53

Application Design Here is the conditional format rule – notice the range of values (between -.01 and 0.01) to cater for small deviations rather than an =0 condition.

54

Pushing Excel

2E. Documentation In an application, dedicated worksheets should be assigned to documentation. It has always surprised me that clients often specifically request that you do not document as you develop; as if it can effectively be done after the fact. They seem to be trying to save money. Now, the concept of saving money I support but not at the expense of the project. What I hear them implicitly express is: “I do not have the ability to develop this application myself but I will not trust a professional to act professionally and will not listen to their advice.” Documentation is one of the most important practices in Excel development. The greater the complexity of the proposed application, the greater is the need for documentation. Also documentation starts with the objectives (do I hear “Don’t write down your objectives.”). This continues with a diagram of the structure and goes on to a narrative explaining the approach, reasoning and some of the methodology that will be utilized. It is a great aid to development and can provide a guide through the issues and records the reasons behind decisions. The value of this is evident to subsequent developers who may need to familiarize with the application in order to either work on it or use it. What many people do not realize is that documentation is valuable to the developer as well. Down the line, a long time later the developer may have to modify the application. It is applicable to users as well. How often have I started a contract at a company and have to analyze the application before I can start. There are 3 sections to document: 1. Design 2. Development (including maintenance) 3. Use/operations Not all aspects need to be developed as you go – some can be done later – there are no real rules to this – the experience of the developer will show here! 55

Application Design Good documentation may include: 1.

Objectives of the application

2.

Outline of the structure – including a diagram

3.

Explanation of the application

4.

List of input

5.

Description of workings

6.

List of outputs (reports?)

7.

An area for definition of variables and range names

8.

Explanation of Naming conventions (EG Date format, Range naming convention)

2E.1 Objectives You should always start with writing down the objective/s of the app. These can be added as you go – it is a good idea to put a date beside the objective so that you have a record of when the specs were altered.

2E.1a Example 1 - Objectives October 2019: The original objective is to develop a Balance Sheet and Income Statement model that can be used as a prototype. for the immediate future – until an ERP application can be installed and adapted. A GL numbering system must be included so it can be used throughout the group of 16 companies. The added complexity is necessary and tolerated because it will allow future features to be developed. February 2020: A Cash Flow Statement added.

56

Pushing Excel

2E.1b Example 2 - Objectives Design Issue: Source of information The Financial Package Cash Flow was chosen as the most important dimension. Requirements: 1.

Plan (Budget)

2.

Record Actual

3.

Analyze according to priority (usually $ Amount) of components

4.

Compare Actual and Budget

5.

Be multi-dimensional – ie. Time (Monthly, Quarterly, Annually), Centers (Type of business, Entity)

6.

Maintain a history

7.

Be easily updatable by a non-technical person

8.

Be able to use Quickbooks as a source and also another TBD ERP system later

9.

Produce Cash Flow projections as well as BS and IS

10.

Cater for Consolidation but use individual entities as source

The basic approach will be to store (In Excel) a data input area that can be used for history. This data base should ENABLE tracing back to source. Therefore it must have internal controls that ensure the integrity of the data. The 80/20 rule: The most significant items will be used – all insignificant items will be grouped into ‘Other.’ If the amount of the ‘Other’ group grows beyond 10% it can be investigated and perhaps broken out further.

57

Application Design

2E.2 Application Structure (Architecture) diagram Structure can also be thought of as the architecture of the application. You can draw a diagram of the intended structure of the Workbook – which can be updated as the application develops. So it does not have to be the finished project but can be added to as you go. This can have beneficial effects on the development as it enables visualization during and at the end of the project (by users). It is an important communications tool with the sponsors (people who are paying you).

2E.2a Example 3 - Structure diagram

This example started as a simple Consolidated Balance Sheet and Income Statement but a Cash Flow Statement was added later

58

Pushing Excel

2E.2a Example 4 - Structure diagram Here is a diagram of the structure of an application that includes a budgeting feature as well as Financial Statements.

In addition you might want to include an intermediate staging area to be used to amend the Prior Year (PY) figures so that you can (for example) prepare a PY+x% basis for the budget.

2E.3 Explanation 2E.3a Example 5 - Explanations This consolidation application enables 16 different companies (in diverse businesses) to be consolidated without altering the source. The model contains a mechanism to enable the development of a generalized chart of GL accounts that can be retrospectively implemented in each company so that comparative figures can be produced for the current and prior year. This involves input of 192 monthly trial balances (16 Cos x 2Yrs x 12Mths) from group company source trial balances. These differ each month due to new accounts being opened in any company. Consistent coding of these GL balances presents a major challenge but once done it can be added to a history so comparative figures can be recalled at any time in the future.

59

Application Design Intermediate combined COAs and steps are: 1. Raw 16 companies x 24 months 2. Combined and converted to General COA 3. Summarized per Natural Account 4. Summarized per Account category for consolidation before adj 5. Consolidated adjustments 6. Acquisition (including Revaluations, Goodwill arising etc) 7. Elimination of Intragroup balances 8. Adjustments to Consolidated T/Bal 9. Elimination of Intragroup transactions involving PoL 10. Summarized FinStats after consolidation adjustments

2E.4 Specific challenges & solution – explanations Most applications face unique challenges that tend to influence the design of the solution. How often have you heard someone say “Why did they do it that way?” This is the opportunity to explain that. It may not be necessary in all cases (but then nothing is).

2E.4a Example 6- Specific challenges & solution – explanations In this application a challenge was that the group consisted of 16 different companies/entities that each had their own chart of accounts (COA) and their own way of coding (allocating) items to these charts. While the goal was to introduce a common COA throughout the group, it was decided that this should not be attempted all at once All the consolidation work should initially be centralized in ‘head office’ where the expertise was available and common decisions could be made and implemented without disrupting operations.. Because of the above the Trial Balance would be imported as is and then converted to a common COA by assigning a number to each item in the application. This means that the Quickbooks charts in each 60

Pushing Excel company could change, be in any order and carry on as usual while the group could implement any changes they wished. The change in COA would be undertaken one entity at a time and GL account numbers would result in only a small change to information and data entry.

2E.5 Functions used (explanations in a separate sheet) During application development there are situations when a complex function or formula is used. Some explanation of these can be included in an explanations worksheet.

2E.5a Example 7 - Functions used For example, if INDIRECT() is used, nested with a VLOOKUP() a future user may have trouble understanding. A brief discussion may add to the ability of the final application to be passed through to users who did not construct the formula. Example description of nesting the INDEX() function to a SUM() a Range column: Example: Sum the 13th column of range TB_MMG_YTDHist SUM( INDEX( TB_MMG_YTDHist,,13 ) )

To copy across use an INDIRECT() function and put CoName in col B and the Col # in row 17 SUM( INDEX( INDIRECT( "TB_" & $B20 & "_YTDHist" ),,O17 ) )

Note the ref to B20 for the name of the company and O17 for the column number. This formula can then be copied across and down. Such an explanation can save a future developer time when added to the documentation. It also provides notes for the original developer if they return at some time in the future (although they could probably be relied upon to be able to read their own code).

61

Application Design

2F. Opening Macro Whenever an application is opened, it may be advantageous to make some changes to Excel option settings, or open at the same place every time instead of where it was closed the last time it was opened. This can be easily achieved by writing a macro that is named Workbook_open(). Unfortunately there is a caveat here. If you have such a Macro in a workbook then Macros have to be allowed and the workbook must be saved in .xlsm format. This protects users from malicious macros but limits the advantages of the technique.

2F.1 Example opening macro code: The following code MUST be in the ‘ThisWorkbook’ module Sub Workbook_open() Call Zoom_01 Call Blank_Cells [Begin2].Select End Sub

When this macro runs at opening, it calls the Zoom sub-routine and then the Blank-Cells sub-routine and then selects the range named Begin2 When this macro is included in personal.xlsx it will not run until the file is saved as a .xlsm file

62

Pushing Excel

2G. Things to Avoid and Rules to follow 2G.1 Do’s Do separate 1. 2. 3. 4.

input, workings, storage of history and output.

It is also a good idea to try to minimize the number of steps and intermediate results since every step will add to the difficulty of maintenance of the application. A diagram of the application is a great aid to following a logical design from the beginning. Do establish a control area for changing values and factors – this is not necessarily the data input – you could call it application metadata. It will include: Constants, parameters, rates, and anything else that will require updates. Do design a clearly defined area for simple and easy input of data. For example you could input Monthly Trial Balances into consecutive columns – do not calculate the monthly differences – unless there is a good reason to do this (no rule is unbreakable). Do use intuitively named ranges (or tables) – not addresses. Do design output to be independent of input and workings. EG: Quarterly and Annual totals should be separate from the input area – in their own area. This could be thought of as intermediate storage or workings. Do design and set up internal control totals so that a user can have confidence in the output (results reported). An audit area can be very useful. Do keep formats and the use of borders consistent to aid usability. Set up and follow a naming policy. This reduces confusion. Work neatly and efficiently to produce an elegant solution makes economic sense which looks professional. If your work looks sloppy it probably is! Use colors to enhance readability and make your presentation look good.

63

Application Design Do use Serif fonts only for text – use san serif for numbers and headings. Do Design applications with a modular approach to development. The more structured and segmental the application is then the easier, quicker and better your final application. Do work in a order of importance. Start with the design from the diagram and establish areas to receive the data, parameters, storage and leave the reports until last. Do Design before you build an application. Document as you go. Do design a Shortcut menu to help a user navigate the architecture (although a user should at least try to understand the structure of the data, workings and assumptions). Do use a cover sheet as an opening page – if appropriate Do use subroutines in structured macros (call them) Do use an update schedule in a separate TAB (Worksheet) Do use Copy/Paste for importing data where possible – or write a macro that will copy/paste into an input area set aside for just that purpose Do use a Dropdown control for choices – referring to a named list Do use 2 digit numbers in places that will sort – EG: filenames 02_Name so that sorting will be correct.

64

Pushing Excel

2G.2 Don’t Don’t mix input with output (IE: Don’t type the input into the output area) Don’t hardcode values and factors that are constants Don’t try to put it all on one sheet Don’t use external links – EG on input data Don’t use shadow databases – use the original database Don’t design for a special report if you might want to develop a general model Don’t put totals etc at the bottom of lists or input that requires renewal that could over-ride those totals Don’t use additional worksheets, stages or layers without a good reason for doing so. Such will add to the complexity of the application without adding any advantage. Of course, the generic answer ‘it depends’ applies. Don’t merge cells unless there is a very good reason to do so. Don’t use dark backgrounds in areas that will print. Don't use OLE dynamically on a continuous basis. Once you have the data do a Copy/Paste Special Values and drop the dynamic link. There can be a disconnect here between the IT dept and the accounting dept; the accounting people will leave the mechanism in place and two years later (24 months) there is still 24 queries accessing the database and there will be 25 next month when it is completely unnecessary. As a general rule – don't live-link unless you have to do it that way! This is going to be one of the challenges of web-based databases (in the cloud) when an internet connection is required. Perhaps the system will handle it but then why stress it without good reason when it can be easily avoided.

65

Application Design

12H Typical use – 12H.1 Sub-ledger 12H.1a M/End analysis Column for each sub-item – this is restricted by the sheer number of columns and it will grow more cumbersome as you add columns

12H.1b Rolling Recons Balance Analysis >> Transactions >> Balance Analysis >> Transactions etc This will handle quite a bit of growth because only the current and maybe previous needs to be available to perform the current reconciliations. History is easily dealt with by worksheets and/or workbooks in a folder.

12H.1c Worksheet = Page Technique Microsoft provides templates for a page technique (a worksheet used as a page in a sub-ledger) – this simulates the old way of a paper ledger. It is powerful and comprehensive but will present challenges because it does not lend itself readily to computerized applications. However it has its advantages even if it is a "paper-simulation."

66

Title: Pushing Excel – Addresses, Application Design by Cliff Beacham ASIN: TBA Copyright © Cliff Beacham 2020. All rights reserved Printed in the United States of America Published by Cliff Beacham Inc, 4621 E Colorado St, Long Beach, CA 90814 This book may also be purchased for educational, business, or sales promotional use. Online editions are also available for most titles in the series

Editor: Cliff Beacham Printing History:

August 2020: First Edition

Trademarks:

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Cliff Beacham Inc was aware of a trademark claim, the designations have been printed in caps or initial caps

Errors and Omissions:

While every precaution has been taken in the preparation of this book, the publisher and author assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein

Small print:

The technologies discussed in this publication, the limitations on these technologies that technology and content owners seek to impose, and the laws actually limiting the use of these technologies are constantly changing. Thus, some of the code examples described in this publication may not work, may cause unintended harm to systems on which they are used, or may not be consistent with applicable user agreements Your use of these examples is at your own risk, and Cliff Beacham Inc. disclaims responsibility for any damage or expense resulting from their use. In any event, you should take care that your use of these examples does not violate any applicable laws, including copyright laws

Most authors might make the claim that their book is different from those already gone before - written by others. This book on the topic of Application Design is based on practical experience with the application (not the help files) and the use in (over decades of using spreadsheets) accounting applications. While there are many people who claim expert status and many more who use Excel in their daily lives there are only a few really expert users. Additionally they tend to not be accounting SME’s (Subject Matter Experts). Professional developers tend to be IT people and not accountants. Accountants who are also experts with Excel are like hen’s teeth – not so many around. So this book takes the reader from the basic way that an Excel® user usually plans an application through to a professional approach using tried and tested techniques and methods. Full of tips and techniques that aim at efficient and effective applications that can be handed to the next guy who has to make head and tail of the app. What has been missing in the accounting workplace is a book that illustrates how to use Excel® solve accounting issues. This book goes far in that direction and includes many tips, tricks and application design issues besides. This is a sub-book – published as a sample of the soon to be published whole book entitled “Pushing Excel.”

US $5.99 / CAN$7.99 ASIN: B07NJX___TBA User Level – Intermediate – Advanced Cat: Business Applications/Microsoft Excel