RSS Feed c9 logo Australia's best motorcycle shop retail software
C9 V5 Progress May 31, 2020 barney

V5 c9 is coming in 2021. Details, motivations, goals and progress

Overview

V5 is a significant reworking of  the c9 core product. For last 10 years c9 has evolved into a functionally complete DMS. That goal achieved, an assessment of whats next. The new goal is to polish c9 until it is the best possible product we can possibly imagine on paper. V5 is the first step towards this new goal.

Note: Original plan was to make v5 a big stepwise/quantum change to c9, dropping it in 2021. This plan is now being reconsidered. Instead c9 product will 'evolve' into v5 incrementally and two or the 6 or 7 or so major components of that delivery should happen before end of this year as part of normal iterative improvements that ordinarily happen with c9. Because of this change in approach, making this post unsticky and unlikely to update it again in future.

C9 Evolution Major events

  • ~ 1992 : C4 rewritten from AB86 into Clarion for DOS. Approx 1 year effort
  • ~ 1999? : business restructured : into c8, Clipstone Yamaha as owners.
  • ~ 2002 : C8 rewritten in clarion for windows. Approx 1 year effort spead over a long time
  • ~ 2004? : business restructured : purchased by Boltons
  • ~ 2006 : Migrate C8's database from Clarion to PostgreSQL. 6 month effort.
  • ~ 2009 : Migrate c8 from clarion to java JVM. 18 month effort
  • ~ 2011 : business restructured : into c9 : partnership with Boltons and Barney
  • ~ 2013 : Migrate devtools from Clarion to Java eclipse. 9 month effort
  • ~ 2018 : migrate to PostgreSQL 10, ongoing
  • ~ 2019 : Rewritten website e-comm code ( v3 ). 6 month effort.
  • 2020 : v5 c9.

Motivations and Design Goals

C9 developed over last 2 decades in an incremental fashion.  Starting with spares only, then adding workshop, units, business, general ledger / backoffice accounting bit by bit and various modules feel and work slightly differently. e.g. discounting on workshop works a bit differently to spares. Unification of internals of the product is identified as something will deliver a number valuable improvements. Design goals with this in mind

Functional goals:

  • Make the product easier to learn
  • Make the product more flexible / powerful
  • Make the product more accessible / featureful to backoffice admin , bookkeepers and accountants.
  • Make it easier to understand and undo data entry errors
    • Better auditing of all changes
    • Better ability to undo everything i.e. no more 'this is an irreversable operation!' warnings. Make everything reversable
  • Keep v5 c9 looking and behaving exactly same as v4. Big changes to be avoided to minimise relearning required.

Capability goals:

  • Unlock often requested behaviour considered to date too hard. such as:
    • FIFO based stock control for more accurate COGs reporting and inventory valuation
    • Ability to easily edit orders and invoices after the fact to quickly repair errors
  • Get rid of advisory locking, replace with optimistic locking model. No more 'job is locked by terminal XYZ' nags.
  • Perfect precision math for inventory. fractions like 2/3 is tracked such that it does not generate rounding errors (On screen you'll a rounded estimate 0.666 but behind the scenes it is stored correctly, so inventory change of + 1/3 + 1/3  + 1/3 will equal 1, not 0.9999) .
  • Groundwork for eventual migration to web based version of c9

Technology goals:

  • Make it easier / faster to add features
  • Make it such that newly added features can be instantly more accessible to more parts of c9, i.e. something added to point of sale, should be reusable within workshop
  • Improve quality control outcomes.
    • More aggressively layer codebase into view/model/biz logic
    • Move critical code paths into java and provide good automated regression test coverage for these codepaths
    • Refactor out all the duplication of functionality in the codebase
    • Work towards eliminating weaker programming practices fostered by 4GL/clarion, main one being heavy reliance on global state which is easily single biggest source of bug reports in v4 c9.

v5 dev timeline

  • Sep/Oct 2019 : original analysis  of what to do next
  •  Nov 2019 :  v5 scope and goals broadly defined
  • Dec 2019 : Dev begins
  • Mar/April 2020 : First working version of c9v5 that is able to generate a simple spares sale invoice.
  • Projected
    • July 2020 : spare parts working enough to be ready for pre-alpha.
    • Sept 2020 : contacts + workshop working
    • Nov 2020 : units working
    • Dec 2020 :   backoffice
    • Jan 2021 : rollout of v5 to new clients
    • Mar 2021 : rollout of v5 to existing clients

Comments on resulting product

Clerk keys

C9 v5 nags alot more for clerk keys. especially when doing things like tidying up orderbook. Possibly will include an option to use same clerk key previously entered in some circumstances such as within the orderbook.

Point of Sale changes

Force sell is being removed.  To make force sell work, instead you'll need to f6 part and manually set some stock on hand.

Ordering Changes

Ordering will change significantly in v5.  Summarising

  • Reserves and laybys will no longer track against an 'order'. Orders will strictly be things needed from supplier
  • Ad hoc ordering is being removed
  • Orderbook more cleanly separates a 'requirement' from an 'order'. More on this below.
  • # being cancelled and backordered now needs to be explicitly enumerated, where previously system would infer this based on excess qty.

Ordering - reserves / laybys

This is a bit of a hack in v4. v5 orders are defined as strictly things that you request your suppliers for.  Reserves will still be visible in orderbook in customer/invoice view.

Open supplier returns, may or may not use the order system, like they do in v4. Unsure at this time.

Ordering - requirement vs order

a request/requirement to source a part and having that part on order. In v5 we will think about things like so:

  • Requirement: Customer A wants <n> parts
  • Action: With respect to the above, c9 has <m> parts on order  to meet this requirement.

But these two things can change more independently of each other than how v4 c9 works. in v4 there are sortof sometimes linked and sortof sometimes independent. This change will make v5 more predictable and consistent but might take a bit of getting used to.

As long as order has not been sent to supplier yet, then v5 c9 keep requirement and action in sync automatically. But as soon as you tell a supplier you want <n>, customer then says, no I just want <m> of those, then c9 order book will work a bit differently in this scenario compared to v4 today.

This will open up more flexible and intuitive behaviors in v5. But existing things in v4 c9 , such as cancel a part, will not strictly do same thing in v5. So a couple of things you currently do in v4 will be different in v5. This does contradict a design goal of keep v5 the same. But in this instance the change is for the better and I am confident it will be easy to adjust to and new c9 itself will provide guidance on this.

For instance consider this scenario.  Order 4 XYZs for Bob.  Tell Honda I need 4 XYZs. Then a different customer, Bill, comes into the shop to refund/return 1 XYZ.  In v5 c9 1 XYZ will automatically assign to Bob and orderbook will flash telling you you now only need 3 XYZs, not 4 so you can try and contact Honda and tweak your order and reduce it to 3. Bob will be optionally notified that 1 XYZ is now available if they are setup for alerts on partial supply.