Modern business management application design specification

Objective

Develop a modern and business management application with standards-based Web technologies. The application should be simple enough for any small business to use, but also automate the reporting requirements of large businesses.

Motive

I have an interest in developing a multi-purpose business administration application for two businesses I manage. Here are some of the motivating factors I have considered:

- Business administration, including financial accounting, takes a lot of time to do manually. - There are a number of free and entry-level accounting packages available ( has risen to prominence recently), however they all tend to automate the simple things and are restrictive by design. For example, they will automate invoice processing up to an artificial limit depending on the value of your subscription. Invoice processing is easy and I don’t want to be set a maximum of 10 invoices per month. What they don’t do is automate quarterly or annual tax reporting or payroll, these things are WORTH automating as doing so can save hundreds of hours a year. - If you want a system that does automate more “complex” tasks then you invariably venture into commercial accounting and ERP package territory which are out of the reach of most small to medium enterprises. We’re talking thousands to millions of dollars. - The calculations required for a fully automated business management system are NOT very complicated. Of course, you always take something to the Nth degree of complexity, but for the requirements of 90% of businesses by volume (1-20 staff) the calculations are not necessarily complex. - Numerous attempts at automating Australia’s overly tedious (but not complex) accounting and tax rules for the mid-market have been attempted but abandoned, even some open source projects have gone the way of the Dodo.

Features

The features of the app can be separated in to “core” and “modules”, however, the design of the app should be almost entirely modular. For the first release of the app we won’t strictly enforce the existence of data in the field unless necessary. For example, some apps won’t let you save a contact unless a billing address is entered. We won’t strictly enforce such requirements until they make sense. Also, this list of features is an overview and will need to be added to with more specific details. For example, The Australian Business Number (ABN) can be validated against the tax office’s formula of issuing one. This is an example of a “nice to have” that would make using the application less error prone. Company setup (your organisation):

- This is where you enter the information about your organisation. Things like: o The organisation’s Legal entity name (e.g. ABC Manufacturing Pty Ltd) o Trading name (if applicable) o Australian Business Number (ABN) o Australian Company Number (ACN) (if applicable) o Type of organisation: Sole trader, Pty Ltd Company, Not for profit, etc o Street address o Postal address o Main phone number (switch) o Fax number o Mobile number o Web site o Contact email

Contacts:

- At the centre of the app is a contact manager. - Standard vCard format for name, number, address, business name, etc. - Make sure each contact has a postal, street and billing address. - Ability to import/export .vcard files for bulk contact transfers. - Upload pic/avatar for each contact. - Ability to classify contacts as: o Customer o Supplier o Partner o Employee o Contractor o Lead (useful for marketing) o Guest (useful for tracking visitors to events, etc) - The view will determine which type of contact is shown where, but as a far as the data store is concerned it doesn’t make any sense to have a different type of contact in a separate database. Keep all contacts together and classify them for later use. - Ability to classify a contact as a “Billing contact” or not. - The ability to tag each contact like tagging a blog post. E.g tag a customer according to an interest “skiing”. - In addition to the regular vcard fields, each contact should have a field for the popular social networks: o Facebook o Twitter o LinkedIn o Google+

Company page:

- The company landing page should generate the key information about the company. - Whether the company is a: o Customer o Partner o Supplier - Legal entity name - Business, or company, number (In Australia there is the Australian Business Number – ABN) - Address and phone number - List the top three contact people - If the company us a customer the account balance: o The amount spent by the customer in the current financial year. o If the account is in credit, how much they have (e.g. overpaid their last invoice by $50 is a $50 credit). o If the account is in debit, how much is owing/outstanding (e.g a late invoice of $200) - If the company is a supplier the account balance. o How much you have spent with that supplier this current financial year. o If in debit, how much do you owe that supplier. o If in credit, how much account credit you have with that supplier.

Product and service catalogue:

- This module is essentially a database of what the business offers and how much it charges for each unit. - Each entry could be a product (physical or digital) or service for an hourly rate or fixed-cost project. - Each item (product or service) has: o A name o Type: product (physical or digital) or service o Cost (fixed or hourly rate) o Description o Image (if applicable) o Sales tax. A way to specify if sales tax applies to the item. You can set the default to be apply sales tax to all items, but you should be able to override this on a per-product basis. - When items are sold to a customer they are added to an account/invoice and the number of units (or hourly rate) is specified. This should greatly simplify creating invoices.

Chart of accounts:

- A chart of accounts is essentially a way of grouping income and expenses into similar types. o https://strategiccfo.com/standard-chart-of-accounts/ o https://en.wikipedia.org/wiki/Chart_of_accounts - To create a chart of accounts you need to add groups that have: o A number for the account o An account name (e.g. “Travel expenses”) o An account type: Asset, Debit, Liabilities, etc o Assets, expenses and liabilities. Assets are things that the company owns like cash savings, property, equipment, etc. Expenses are things that the company must pay like rent, wages, marketing, etc. Liabilities are things that the company owns but are deemed to be at risk of being lost, like employee leave entitlements. o Ability to have account groups so more than one type of account can be grouped.

Accounts:

- Accounts is broken up into two main areas: Accounts receivable and accounts payable. - Accounts payable: o What expenses need to be paid to suppliers o New invoices should be tied to suppliers in the database o Payment terms should be entered in and reminders sent for due accounts - Accounts receivable o What invoices need to be paid by customers o New invoices should be tied to customers in the database o Payment terms and other settings should be pulled from invoice settings.

Invoicing:

- The invoicing module should be capable of generating PDFs for quotes, invoices and staff payslips (see more details about payslips under “payroll”). - Look at a tool like Reportlab or http://mstamy2.github.io/PyPDF2/ to generate the PDFs on the server for sending, downloading and archiving. - Support customisable invoice templates for different clients. - Support generating an optional “quote” for a customer which is essentially the same as the final invoice but clearly labelled “Quote” and the length of time it is valid for. E.g. “Quote valid for 60 days”. - Seamless transition from Quote → Invoice (sent) → Invoice (paid) → receipt (sent to customer) workflow status for each invoice. - The invoice should generate: o Company logo and contact details o The customer name and contact details o A unique invoice number. Could be broken down into DD-MM-YYYY- ClientNumber-JobNumber so as to avoid any repetition but also be human readable. o Itemised list of deliverables o Total cost with tax itemised o A purchase order (PO) number if required by the client. POs are best handled on a per-project/job basis. That way one PO can be used across multiple invoices. For example, if a project/job is $3000 and the client wants to be invoiced across three quarters to fit in with their budget, attach the PO to the job and tell the billing system to send an invoice to the client quarterly. o How to pay details. E.g. bank account details, paypal, online payment gateway URL, etc. o Payment terms (e.g. 14 business days)

Payroll: - Payroll is essentially a summary of an employee or contractor’s hourly rate, the hours they worked plus additional benefits like superannuation. - A global setting for desired the pay period: o Weekly o Fortnightly o Monthly o Quarterly - The ability to do ad-hoc pay runs for individuals, groups of people, or the whole company. - The payroll module will pull together into a PDF the following properties for an employee or contractor which will most likely be defined in the employee setup page: o Employee name o Employee number o Pay date and period o Hourly rate (for all staff, not just people who work on an hourly rate. i.e. full time staff still have an hourly rate) o Annual salary (if applicable) o Superannuation rate and amount (this can be pulled from the superannuation module) o Any bonuses o Any leave loading o Gross pay amount (before tax) o The amount of tax taken out o Nett pay amount (after tax) o The final pay figure that is banked. o The employee’s bank details where the money is being transferred to - The payroll module also needs to export a summary digest of the final pay details which is sent to the bank for processing. I will check the formats, but it’s most likely something like a .CSV file that can be imported by Internet banking applications. - The same needs to be done for superannuation payments. Super does not strictly need to be paid with each payroll, but doing it both in the same process should save a lot of administration time and keep employees happy. It’s also convenient to generate the Super amount on the payslip document. - I will provide examples of what a typical Australian company payslip looks like.

Superannuation:

- The Australian government mandates 9% superannuation for all part time and full-time employees. - The superannuation is paid in addition to an agreed wage or salary. - A superannuation page for each staff member where the rate can be set and the fund details can be set. - An admin page where the “default fund” details can be set (most companies need to have a default fund where payments are made if an employee does not provide their own. Timesheets:

- I hate timesheets as much as the next person, but unfortunately many companies live or die by them and would not use an accounting application if it didn’t support timesheets. - Each employee or contractor can attach a service item and hours worked on that item to their timesheet. - Worked performed on an item can be billed against a client project. - If no client specified, work performed goes against general “labour” or “staff” costs in the balance sheet. - Timesheets can be saved as “templates” to avoid having to complete a timesheet for roles that do not require it. E.g. A receptionist is likely to work the same number of hours every week so no need to fill out a unique timesheet every week. - Ideally the timesheet module uses the same calendar/notification module code base to handle daily, weekly and monthly summary views of the timesheet. - Furthermore, the staff timesheet data for contractors should feed into the payroll module for wages payments. o A person’s salary will be specified in the employee setup. o Full-time staff won’t need to specify an hourly rate for work performed, just the fact they have worked on a particular project is fine. o The timesheet of a casual worker/contractor should feed into payroll.

Expenses:

- This is another area that consumes a lot of manual processing time, but is easy to automate. - Specs to be provided, but essentially: o Enter expense amount (inc sales tax) o Against an account (e.g. Travel expenses) o Against a project (e.g. Client Web development project) o Expense goes for approval o Approved expense added to next payroll o Add scan of receipt o More to be provided...

Billing:

- The billing system module should support event-based billing and time period-based billing. Event-based billing is when an invoice is sent to a client in response to their action of signing up to a new service. Event- based billing can happen on any day at any time. For example, a customer signs up to a new mobile phone plan on Wednesday at 10pm so their next bill gets generated (if monthly cycle) exactly one month later. Time-based billing, however, can be specified depending on the job or client requirements. The billing day can be set to occur at the start or end of the cycle. Billing cycles can be set to: o Daily (unlikely to be used in practice) o Weekly o Monthly o Bi-monthly (every 2 months) o Quarterly (every 3 months) o Bi-annually (every 6 months) o Annually - Event-based billing should help reduce the load on the system if it was just time period-based (e.g. hundreds of invoices and bills need to be generated and sent at the start of the month). - Distinguish between a fixed-cost project and a recurring revenue stream. In the event of a fixed-cost project the billing system can be told to either invoice the project in full or split it across a specified number of progress payments using the recurring billing engine. E.g. divide the total cost by three and invoice over three months. [Note: these settings can be applied here or pulled from the project/job settings for that client’s job]. - Having these flexible options for billing will enable the system to comfortably handle products and services (including subscriptions). - If feasible use the same recurring billing engine/module for accounts receivable (invoices) and payroll. - The bills get sent to the billing contact associated with the contact. - Will need some rudimentary email system to send invoices out via email. - Look at another channel like SMS to notify people of new bills. - Reminders should be sent out before the bill is due. If 30 day payment terms, one reminder per day after 20 days has lapsed. Once the invoice is marked as paid the reminders stop and a “Thank you for paying” message is sent. - The billing system will send reminders before or after the due date depending whether the product/service item is marked as “pre-paid” or “post-paid”. E.g. Web hosting is likely to be pre-paid whereas a consulting/development service is likely to be post-paid.

ASIC:

- This module helps the business owner deal with ASIC – the Australian Securities and Investments Commission. - Only relevant to companies and partnerships, not sole traders. So can be “enabled” in the admin area. - Business name and ABN - Company name and ACN - ASIC corporate key (like a PIN, should be stored securely) - Company registration date - Company annual statement renewal fee date and reminder sent - Business name renewal date and reminder sent - Other features TBP...

ATO

- This module helps the business owner deal with the ATO – the Australian Taxation Office. - Contact numbers and mailing addresses - ATO business portal credentials - The companies GST reporting scheme – quarterly or annually - Auskey details - Look at automated reporting requirements - Other features TBP...

Reports:

- Quarterly Business Activity Statement. This is a summary of the amount of sales tax the business has received and the amount it has paid. The sample report and calculation will be provided. - Annual BAS. Same as quarterly but businesses can elect to do it yearly. - Payment summaries for individuals. Essentualy a basic summary of how much an employee has earned over the financial year and how much tax was withheld by the company. - Company tax return. A summary of revenue less expenses. Full report and examples to be provided.

Global search:

- The app should have a global keyword search facility with the results presented in order of relevance. - This could be done with an existing search app or open source code that can perform searches on postgresql.

Global notifications:

- This is not mean to be a Web-based email system but it is functionally equivalent. - Notifications are mean to be read in the app, but can also be sent to an email address. - There might be existing calendar code that does this. - A feed of all important notifications and reminders. o Accounts payable o Overdue invoices o Set reminders (e.g. company domain name renewal, ASIC registration fees, quarterly tax payments) o Any change to settings, contacts, accounts, payroll, etc

Global tooltips:

- A global way to add tooltips to any part of the application. - Something like opentip.org should do the job. - Ideally tooltips should link definitions to a glossary page in the application that explains and references important words and concepts.

Geneal features:

- Modern front-end interface with bootstrap and jquery (or backbone.js) - Generate PDF invoices with customisable templates - Allow invoices to be generated for recurring bills. More details will be discussed. - Expense uploads. Upload a file (image or pdf) and attach to expense details page (amount, tax included, reason for expense etc) - Quarterly and annual sales reports. This is a basic calculation and the method/report will be provided. - Annual sales report. Again another basic calculation and the method report will be provided.

Architecture

The application will be developed according, or similar, to the following architecture.

- Scalable RDBMS like PostgreSQL - Object oriented programming language like Python - Leverage a Web framework like Django - Run on any industry-standard Web application server like Apache, Nginx - Ability to run in-memory like memcached - Modern, clean presentation layer build with an industry-standard JS framework like JQuery, Angular.js or Backbone.js - Modern theme like bootstrap - Modern icon theme like Font Awesome - Responsive HTML5 design for access via desktop, tablet, smartphone, etc. - A REST API for data integration (e.g. Piston)

Approach

A key design consideration of the application is to use open source software and standards-based development practices. Likewise, the application itself should reuse as much code as practical. I propose the following approach to how the application is developed. This is a basic schedule and can be improved/altered by the developer.

- Decide on the application technologies that will be used.E.g: o PostgreSQL o Django o jQuery o Bootstrap o Font Awesome o Opentip o Celery o Any other open source components or templates that can be used to make developing the app easier.

- Setup the application development environment. Once the components have been chosen set up the development environment in GitHub (or similar) and check that all the components “play” well together and note all dependencies and how they will be satisfied in the release cycles.

- Setup the standard template that will be used as a basis for all pages in the app. Things like: o Page design/layout o Menus/Navigation bars o Headings and sub headings o Theme/CSS (e.g. Bootstrap) - Develop or integrate a collection of reusable components, or “applets”, that will be used throughout the app. Things like o PDF generation o Image/document uploader o List views (listing invoices, payslips, contacts, etc) o Forms (a form tool might help), dropdown lists, check boxes, buttons, etc o Date selector o Calendar o Notification system/Emailer o Wiki o Search o Administrators, users and groups o Tagging

- Start developing the modules in order of what is likely to be required first. Feel free to be inspired by what other open source projects have done. Here is a rough order of development priority for the modules: o Company setup o Contacts o Product and service catalogue o Chart of accounts o Accounts receivable (Jobs/projects) o Accounts payable (Expenses) o Invoicing o Billing o HR o Timesheets o Payroll o Reports – BAS o Reports – Company tax return

Code reuse

One of the reasons I’m favouring a popular Web framework like Django for this application is there exists a lot of open source projects where the code could potentially be reused. Possible examples:

- vCard import/export - Addressbook - PDF generation - Invoice templates - Profit and loss statement - Recurring billing - Email integration - Bank statement imports (.csv) - Accounting file format imports (//xero)

Possible components

Forms - https://github.com/gregmuellegger/django-floppyforms Other systems

There is a mixed bag of accounting and ERP systems available (both open source and proprietary), but as outlined the Motive section none of them do what this system is designed to do. That said, I don’t believe in “not invented here syndrome” and encourage developers to look at what others have done to make their task easier. Here are some similar applications:

Australia:

- Symbol accounting. This is open source and the closest to a pure accounting app for Australian companies. The project has been abandoned, but the business logic and documentation are still valid. The Symbol documentation should be referred to when developing this app.

- Fivedash. Another open source project that has been abandoned. This is more like a basic CRM than financial accounting tool, but nonetheless the source code is available (web.py).

- Manager.io. Free for desktops, paid for server and cloud editions. This is the closest thing to this app in terms of design (jQuery Bootstrap) and features, however, it is built on .Net which may pose challenges with scalability and roadmap. The documentation (http://www.manager.io/guides/) is ideal for understanding how an app like this should work. Feel free to download the app source code and see how it works.

International:

- Prometo ERP (now forked as Django ERP, but project looks stalled).

- ERPNext. This project is quite mature and well supported, but is not designed for Australian requirements. The developers wrote their own framework (frappe) to develop this app which may not be best practice in the long run.

- AmberDMS. Interesting project from New Zealand (the developer also lived in Australia for a few years). It does billing and basic accounting and is well documented. Unfortunately the accounting side has stalled and the recent focus has been on billing only.

There is a list of open source invoicing, accounting and ERP package too boring to mention, but they all don’t meet the design goals of this app (see Motive).

- https://erpnext.com/ (python) - https://github.com/frappe/erpnext - https://github.com/dulaccc/django-accounting (django) - http://bugs.sleepanarchy.com/projects/acorn-accounting - http://www.celeryproject.org/ - http://django-hordak.readthedocs.io/en/latest/index.html E-commerce systems which might be helpful http://oscarcommerce.com/ http://cartridge.jupo.org/integration.html#tax http://getsaleor.com/

Other open source accounting/ERPs

- Gnucash - Skrooge - https://github.com/metasfresh/metasfresh - https://github.com/axelor/axelor-business-suite - https://github.com/inoerp/inoERP (PHP) - http://www.scipioerp.com/ - https://wedevs.com/