It strikes me as the problem is being overthought. If a spreadsheet can handle the calculations, it can’t be that complicated.
If a spreadsheet can handle creating the proper csv for export and then import into gnucash, again, it can’t be that complicated. The complications are jurisdictional and apply BEFORE any transaction entry in csv form is generated. Maybe you accomplish this with a spreadsheet, maybe a python module or maybe even a webapp. The end result just needs to be a csv that can be imported into GnuCash. If you want to take it a step further, use the APIs to write the data and skip the csv step. I’d guess a plugin-module is possible, but it isn’t even necessary. I’d suspect plenty of people are using some combination (or other) solution that I’ve already mentioned. It’s just that they haven’t published it so no one knows about it. Someone out there is calculating payroll and automatically importing the resulting transaction to GnuCash, we just don’t know who they are or how they are going about it. (and perhaps their’s isn’t the best method even) Regards, Adrien > On Jul 26, 2018, at 5:40 PM, R. Victor Klassen <rvklas...@gmail.com> wrote: > > 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. _______________________________________________ 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.
