V5 fresh new battle plan

Originally the plan was to create c9 v5 so that once it is ready it will be 100% packed with a heap of things. This plan is now no longer the go. Everything planned for v5 is simply too big, bigger than anything c9 has attempted to date and simply just too much to drop into a single update.

Instead plan is to break v5 up into chunks. Deliverables and content of these new chunks are:

Version	Deliverable	ETA
5.1	Backoffice, General Ledger and BAS Reporting	Dec 2020
5.2	Spare Parts	Mar 2021
5.3	Customer : AR, AP and Deposits etc	May 2021
5.4	Workshop	? Sep 2021
5.5	Units	? Jan 1 2022

The other issue with original plan for V5 was there was no clear strategy on how to actually get it out.  V5 was being built in part as a new product without any clear vision on how to get v4 systems upgraded to v5. There was this vague hand wavy we'll figure it out later sort of approach, but no really clear or tested idea how to do this.

Essentially the original plan for v5 was the complete opposite of how c9 ordinarily gets things done

• Massive monolithic change instead of small incremental changes
• No clear plan on how to get it to existing clients instead of being existing systems first focused

There were plenty of reasons for originally doing v5 very differently. Sometimes it is worthwhile looking at doing things in a radically different way to free yourself from existing constraints and open up possibilities. Assumptions for doing things differently were constantly tested eventually decided those assumptions were faulty. So back to the tried and true way we move c9 forward.

So short short version, C9 V5 is coming soon. At at least a part of it is. By December, v5 c9 will be here. What exactly is this bit?

• Reworked way of storing c9's General Ledger
• Removing existing Activity part of c9 which is substantially used for BAS Reporting. Instead c9 will switch to encoding BAS information in the General Ledger itself using tax coding system: which is standard methodology used in dedicated accounting products like Xero.

So ordinarily a basic Journal posting will look like so. What V5 c9 will add is the tax code column to the journal, migrating this information from old activity dataset into the GL itself.

Code	DR	CR	Tax Code
Asset – Inventory		50
Costs – COGS	50
Sales		450	GST On Income
Sales		20	GST Exempt Income
Liability – GST owing		45
Asset – Cash	515
Aged Trial	565	565

This will mean better fine tuned BAS reporting in c9 since coding now operates on a line level instead of transaction level and there are more codes.

Removing old activity system and replacing it with V5 general ledger will deliver a number of other really useful things

• Improved surcharging, rounding and voucher support.
• Improved ability to fixup payment method errors. Previously you couldn't change payment method involving bank etc. Now you will be able to
• Improved cash and bank rec tooling.  Txn lines will generally be simpler and smaller so in bank rec should be easier. Still some work to validate things here but confident it will make things easier

A big part of v5 backoffice is a significant simplification of the computer program code that powers c9.  Activity / General Ledger stuff is pretty fiddly and a big motivator for whole v5 thing.  Getting this sorted is a critical internal goal for c9 to keep things moving.

Spare parts March 2021

This is where the real functional gains of V5 will become obvious. Things you'll be able to do:

• Easily modify invoices / customers orders after the fact : to quickly substitute parts etc.
• FIFO based inventory pricing for more accurate COGs
• Smarter / more seamless multi pickup / receive etc.

The original v5 project, what I've essentially being doing for last 6 months is building a version of c9 that can do all of these things plus heaps more. This work is now largely considered a proof of concept / R&D which helped prove out and fine tune the V5 design : which helped it through several significant iterations. Alot of this R&D work can be lifted wholesale and dropped in once 5.1 is ready so likely timing estimates here are excessively conservative.