When I think of the requirements for payroll, it seems like it would require more than a “plug-in” that accepts parameters that vary by jurisdiction. It would need to be more like a full programming language (well, not full - arbitrary loop controls not required - for language geeks, it would likely be regular, not even context-free). Having written a (brittle) program to generate payroll for Ontario, Canada, for the special case of agricultural workers - and yes, it is that specific - I could imagine (if I had the time and inclination) writing a program that handled all the cases of payroll for any employment class in any province of Canada. It would likely be several hundred lines of code, and refer to a database of probably a dozen and a half parameters per jurisdiction.
Any idea that that would be universal beyond Canada would be fantasy. It might be easy, it might be hard to generalize to the US states. But it would be quite a lot of work to verify it worked for all 50 states - which is to say the structure would work, without getting the parameters right. And those are likely two of the most similar super-jurisdictions. It might eventually get easy to add jurisdictions. But it might not. But my point is that I would expect to need to encode an algorithm per jurisdiction, not just a series of parameters (like tax brackets, basic exemptions). > On Jul 26, 2018, at 11:28 AM, John Ralls <jra...@ceridwen.us> wrote: > > > >> On Jul 26, 2018, at 7:51 AM, John Ralls <jra...@ceridwen.us> wrote: >> >> >> >>> On Jul 26, 2018, at 6:01 AM, Maf. King <m...@chilwell.net> wrote: >>> >>> On Thursday, 26 July 2018 12:36:27 BST Mike or Penny Novack wrote: >>> >>>> >>>> Saying that no third party has expressed interest in writing something >>>> that would send a feed to gnucash ignores that gnucash does not have the >>>> capability of (properly) dealing with batch feeds. >>>> >>>> Michael >>> >>> Why do the words "chicken and egg" pop into my head...? >>> >>> IIRC, the original Business Features added by Derek were a module. One >>> could >>> theoretically compile GC (1.6 or 1.8?) with a flag and the whole A/P & A/R >>> subsystem wouldn't exist. But that may be the 20 years that John referred >>> to! >> >> No, Derek isn’t a 3rd-party developer. He's very much part of the core team >> and has been for most of those 20 years, though he’s shifted his >> contributions from coding to maintaining the infrastructure. > > It does occur to me, though, that more broadly there has been third-party > interest, just not in writing GnuCash plugin modules. Doug Doughty’s reports, > for example, are a different form of plug-in. Sébastien de Menten’s piecash > is completely external to GnuCash, using SQLite to directly access GnuCash > databases is another example. Anyone who’s used the GnuCash API or Scheme and > Python bindings is a 3rd party extending GnuCash, even if they don’t publish > their work for others to use. > > Regards, > John Ralls > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
