Considering a fork for implementing MySQL C library (multi-user) - thoughts?

[Alex Aycinena]

>
>
> ---------- Forwarded message ----------
> From: stuartb <stuart at buckhill.co.uk>
> To: gnucash-devel at gnucash.org
> Cc:
> Date: Wed, 7 Jan 2015 10:50:11 -0800 (PST)
> Subject: Considering a fork for implementing MySQL C library (multi-user)
> - thoughts?
> Hi GNU team,
>
> We have been looking for an open source accounting system to connect to, to
> provide additional functionality we would rather not have to code ourselves
> (reconciliation, all the reporting, etc) as we have a system producing
> invoices, transactions and so on, using double-entry principles.
>
> We are considering using a small middleware component to map our tables and
> your SQL tables, and after investigating the DB structure this seems pretty
> straight forward to do.   This component would double up as suitable for
> mapping to any other accounting system in the future if our customer(s)
> require us to connect to anything else - but for small business situations,
> GNU seems perfectly suitable.   We would rather not re-invent the wheel.
>
> We considered a workflow something along the lines of:-
>
> Our system -> Create new invoice -> automatically generate commission ->
> create the various transactions required (automatic journal posting).
>
> Our system would create a unique invoice ref and then create a sync job,
> ready to copy into the gnucash database - generating the GUID's and
> following the data structure to ensure data consistency.
>
> After a quick review, these are the initial problems we would need to
> overcome:-
>
> 1. Not loading entire dataset at load of application.  Our system is some
> instances generates a significant number of invoices, with millions of
> individual transaction postings - we can't load the entire dataset into
> memory every time someone opens the application.  It must read from the
> database in real time and "JIT" load data from the MySQL database.   I
> believe we may be able to achieve this with some sort of DAL which would
> sit
> in front of GNU or use the MySQL client library and change the code to
> query
> the data - without further investigating I am not sure of the potential
> work
> required here.  Please feel free to throw your thoughts and ideas across.
>
> 2. Not saving entire dataset on-save, but only the changes made, in real
> time.
>
> 3. Adding support for the MySQL client library for the above and generating
> the queries needed to read and write the necessary data?
>
> 3. Adding foreign key constraints to the database to avoid data corruption
> (should be simple to do)
>
> 4. Making use of MySQL triggers to create transaction safe auto-incremented
> numbering for invoices/credit notes, etc
>
> 5. Support creation of transactions from gnu back to our system, not just
> from our system to gnu
>
> Other notes:
>
> We noticed the use of GUID frequently being used.  This should make our
> lives easier regarding syncing.  It should be possible to add a
> "last_updated" column in each database table and then use MySQL triggers to
> update this on change.  In our applications we always use a "date_created"
> +
> "date_modified" col for every table, with full datetime info stored to
> allow
> us to track changes.  In theory we could implement this without touching
> gnu
> code and benefit from this additional information in the case of multiple
> writes.
>
> Why would we do this?:
>
> Due to the nature of our application (typically tens of thousands of
> transactions a month per instance), we have created a bespoke highly
> automated approach to accounting which avoids any manual posting for day to
> day working.  We never set out to create an alternative to Quickbooks/Sage
> -
> our accounting module was simply created as a means to an end.  However our
> customers are so fed up with Quickbooks and Sage (and their own legacy
> in-house systems dating back 30+ years in some instances) they are piling
> on
> the pressure for us to further develop our accounting module so they can
> avoid using said packages.   When investigating their business requirement
> it turns out we would need to re-create a lot of the functionality found in
> gnucash/qb/sage (reconsolidates, reporting, expenses, etc) - which we would
> rather avoid.  Only accountants in our customer's organisations require
> this
> data and they will be happy to use gnucash to access this additional
> information.  General viewing of invoices and transaction data can continue
> to happen in our own system via a web interface for other users.
>
> Catch 22;  do we invest the time branching gnucash and creating an
> abstraction layer to MySQL to allow us to have a multi-user concurrent
> active-active environment, or do we start developing our own platform to
> replicate all the years of hard work which have been invested in an
> existing
> solution?
>
> I'm posting this topic hoping for gnu dev's to leave their thoughts on what
> might await us if we embark on the branch -> develop route!
>
> Thanks for listening!
>
>
>
> --
> View this message in context:
> http://gnucash.1415818.n4.nabble.com/Considering-a-fork-for-implementing-MySQL-C-library-multi-user-thoughts-tp4674947.html
> Sent from the GnuCash - Dev mailing list archive at Nabble.com.
>
>
I think you've picked the wrong product for what you want. I would suggest
you keep looking for something else.

Alex