Modern business management application design specification Objective Develop a modern accounting 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 (Xero 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.