2016-01-15 GnuCash IRC logs

01:21:44 *** Mechtilde has joined #gnucash
02:05:44 *** Mechtilde has quit IRC
02:52:08 *** BuschMan has joined #gnucash
02:55:02 *** BuschMan has quit IRC
03:15:38 *** fell_ has quit IRC
03:18:56 *** Mechtilde has joined #gnucash
03:46:48 *** aqua___ has joined #gnucash
03:56:19 *** nomeata has joined #gnucash
04:06:03 *** CDB-Man has quit IRC
04:07:07 *** CDB-Man has joined #gnucash
04:59:28 *** aqua___ has quit IRC
05:37:03 *** rubdos has joined #gnucash
05:44:37 *** fabior has joined #gnucash
06:32:28 *** ErKa has joined #gnucash
06:47:50 *** Jimraehl1 has left #gnucash
06:52:36 *** Jimraehl1 has joined #gnucash
06:56:24 *** warlord has quit IRC
07:42:07 *** fabior has quit IRC
08:11:48 *** Mechtilde has quit IRC
08:15:51 *** Mechtilde has joined #gnucash
08:26:34 *** mikee is now known as mikee-afk
09:06:02 *** fabior has joined #gnucash
09:25:59 *** fell has joined #gnucash
10:16:07 *** fabior has quit IRC
10:58:32 *** Mechtilde has quit IRC
11:17:09 <codesmythe> jralls: In the previous gtest discussion, you mentioned that the gmock tarball includes gtest. That does not seem to be the case for https://github.com/google/googlemock/archive/release-1.7.0.tar.gz so I am wondering if you are getting googlemock from somewhere else?
11:56:06 *** MarcGuay has quit IRC
12:13:41 *** MarcGuay has joined #gnucash
12:15:26 *** Mechtilde has joined #gnucash
12:33:22 <jralls> codesmythe: Yeah, I got it from the old Google Code site, which may not exist anymore. Tarballs on github are generated on-the-fly from the repo, so it can't include material from another project. There might be a way to work around that with a subproject, don't know, but they didn't do that. In fact it looks like they restructured it a bit, removing the gtest subdir. They really should have changed the version number when
12:33:22 <jralls> they did that.
12:34:44 <jralls> BTW, should I push the _pkgconfig_path_old change to GncFindPkgConfig.cmake?
12:44:43 *** rpg has joined #gnucash
12:46:46 <codesmythe> jralls: Yes, go ahead and push that change. That section of code is copy/pasted from cmake upstream. That makes two cmake/pkg-config bugs I need to file upstream.
12:46:48 *** nomeata has quit IRC
12:47:28 <jralls> OK. Wow, that's not confidence-inspiring.
13:25:52 *** MarcGuay has quit IRC
13:39:08 *** MarcGuay has joined #gnucash
13:57:33 *** KaiForce has joined #gnucash
13:58:41 <KaiForce> gnucash is working correctly and I've not been having any issues with it. Anyone else run into this?
14:00:08 *** warlord has joined #gnucash
14:00:09 *** gncbot sets mode: +o warlord
14:09:15 <jralls> KaiForce: We hope that GnuCash working correctly with no issues is the common experience. Presumably not what you're asking about.
14:33:23 <KaiForce> jralls: I stop here occasionally to express my gratitude for this great program, in my own way.
14:33:46 <jralls> OK. Thanks.
14:35:37 <KaiForce> Years ago Intuit crippled my fully functional and working program, infuriating me and causing me to seek an alternative. They lost a customer but did me a favor.
14:56:58 *** MarcGuay has quit IRC
15:12:22 *** CDB-Man_ has joined #gnucash
15:13:30 *** CDB-Man has quit IRC
15:23:07 *** Mechtilde has quit IRC
15:51:05 *** fell_ has joined #gnucash
15:53:05 *** fell has quit IRC
16:06:41 <codesmythe> jralls: One part of my latest PR should have been submitted against maint; the other two are master only.
16:07:15 <codesmythe> The first is to backport your comment at CMakeLists.txt:443 to maint.
16:07:40 <codesmythe> The second is to remove the execute_process at line 446, which was only ever in master.
16:08:14 <codesmythe> The third was to remove COPYING and INSTALL in lines 473-474.
16:08:48 <codesmythe> I'll close the PR and redo.
16:17:15 *** rubdos has quit IRC
16:34:20 <jralls> codesmythe: OK. Try to make the two as similar as possible. Obviously the version number and boost stuff must be different but we want the rest to be the same.
16:35:43 <jralls> cdstty sane
16:36:08 <jralls> Sigh. I wish focus would follow my eyes.
16:40:40 <warlord> heh
17:34:11 *** nomeata has joined #gnucash
17:52:45 *** altrus has joined #gnucash
17:52:50 <altrus> Hi!
17:56:07 <altrus> We're using gnucash for our business, and pretty happy with it. We're happy to support open source development, so I was wondering whether there was a mechanism in place for paid feature development. Alternatively, whether there would be another developer interested in implementing some features, for which we could either pay for or donate to the project.
17:58:08 <warlord> altrus: generally it either requires finding a dev willing to take the gig. There's not really a good "bounty program" in place.
17:58:50 <altrus> I assumed as much. And you're right - I wasn't sure about what the best mechanism might be to broadcast the opportunity.
17:59:37 <altrus> Which is to say, we're happy to support a developers contribution to the program, or else the program itself, but I don't know the best way to go about it.
18:01:24 <altrus> Is there a dev newsgroup I could post on? The primary feature we're looking to implement is a (reasonably) well documented interface for ETFs with Canadian Banks.
18:02:10 <altrus> The problem is that it might require development of a less defined, and more nebulous, feature of payroll handling. I haven't looked at the code, so I'm not immediately sure how tractable that is.
18:03:39 <warlord> gnucash-devel mailing list.
18:03:50 <warlord> It would help if you have a well-defined set of requirements for what you need done.
18:04:02 <altrus> Definitely have it for the API.
18:04:39 <altrus> Actually, would you mind it if I bounced it off you prior to posting it?
18:05:12 <warlord> Sure. (I'm a bit distracted so I apologize if I take a bit to respond)
18:05:31 <altrus> No worries.
18:06:26 <altrus> The two aspects are this: 1) We're looking to automate fund transfers. We want the ability to have gnucash export a file, that we can later submit to our bank, that includes the necessary information to send money between any Canadian bank.
18:07:24 <altrus> The problem I see is that this falls within the scope of a bigger problem, which is how to handle payroll. Right now, we just specify different transactions for different people, which, ultimately, makes it a bit harder to validate things like year end statutory deductions, etc.
18:08:45 <altrus> Which means that what I'd really like is a mechanism to extend employee profiles to handle payroll data - allowing us to easily specify which parts of the transactions are going to various statutory deductions (and associated employer remittances), and then generate a file that we can upload to our bank to pay everyone.
18:09:51 <warlord> payroll is a very very hard problem
18:10:02 <altrus> I know. I assumed as much.
18:10:21 <altrus> Right now we just use a big split transaction.
18:10:32 *** nomeata has quit IRC
18:12:04 <altrus> It struck me that the current employee structure may have been intended to eventually meet the needs of payroll, but was subsequently abandoned.
18:17:20 <warlord> Some of it was intended to begin that process
18:17:59 <warlord> But payroll is a huge morass of withholdings and taxes and limits... and each locale has their own rules.. So really you need a framework to plug in those rules.
18:19:24 <altrus> I'll be honest; that's probably the wise, sustainable, thing to do, but we already calculate all that seperately. All we would need are extra rows that we can credit various payroll-related accounts, like, "Employer EI", "Employee EI", etc.
18:20:31 <altrus> All we need is a sane mechanism of recording it - we can calculate it ourselves.
18:21:02 *** KaiForce has quit IRC
18:39:56 *** rpg has quit IRC
18:40:15 <warlord> altrus: that's easy -- just add new split rows for each withholding.
18:40:23 <altrus> Exactly
18:40:27 <altrus> We already do that
18:40:29 <warlord> GnuCash can do that now.
18:41:07 <warlord> So I guess I dont understand your problem?
18:41:12 <altrus> The problem comes to this; when it comes time for year-end reconcilliation, we would like to run a report against everything hitting the accounts associated with a specific person.
18:41:34 <altrus> Right now, it's really cumbersome to do - unlike vouchers, where there is a "company report" feature, there's no such feature.
18:41:40 <warlord> That sounds like you just need a special report to read in your payroll transactions and process them properly.
18:42:09 <altrus> Exactly - except there's no real way to associate that with a specific person.
18:42:23 <altrus> or employee, outside of the whatever you call the transaction.
18:42:26 <warlord> Sure there is.. The Description
18:42:33 <altrus> Right.
18:43:20 <altrus> Except vouchers, which also associate with an employee, are prettier and also allow you to generate an invoice (aka paystub), that a custom report won't necessarily let you.
18:43:31 <warlord> payroll transactions with the same description (employee name) get collected together.
18:43:38 <warlord> Sure it would
18:43:41 <warlord> AN invoice is just a report
18:43:45 <warlord> there is nothing special about it.
18:43:52 <altrus> ...
18:43:58 <altrus> Really?
18:44:09 <warlord> yes, really. I did write that code afterall.
18:44:51 <altrus> This is crazy :-p
18:45:01 <warlord> what's so crazy about it?
18:45:02 <altrus> If I goto business > employee > employee overview
18:45:51 <altrus> Are you telling me that I can structure the transactions so that when I run the "employee report", I see it all there?
18:46:02 <altrus> Or perhaps I'm not understanding how to make custom reports?
18:46:07 <warlord> No, you will need to write a report.
18:46:26 <warlord> But ALL you need to do is structure the transactions and write a report.
18:46:32 <warlord> so really, the only work is writing a report.
18:46:39 <altrus> This is awesome.
18:47:23 <altrus> So in fact, the only thing I would really be requesting is a mechanism to group a bunch of transactions, and, using their associated employee information (like banking info), generate that into the ETF file format?
18:47:58 <warlord> Basically, I would iterate over your "gross payroll" account and for each entry collate based on Description, and then you can sum buckets based on each split.
18:48:43 <altrus> (As an aside, part of the problem is the description field for us changes - we use something along the lines of, "Payroll - <NAME> - Conf# or Chq #"
18:49:05 <altrus> so we're really just searching across names.
18:49:13 <warlord> Dont do that. Put the check number into the 'num' column, and you know its payroll because it's in the Payroll account.
18:49:25 <altrus> Oooo
18:49:34 <altrus> So put all the confirmation numbers there.
18:49:41 <warlord> yes
18:49:49 <warlord> Description only needs the employee name
18:49:50 <altrus> (We record both the chq# and the bank transaction number)
18:50:17 <warlord> Sure, you could put both check# and bank transaction number in the num field.
18:50:19 <altrus> You're so smart.
18:50:31 <altrus> Thank you very, very, much.
18:50:35 <warlord> you're welcome
18:50:50 <altrus> I don't suppose you're available to work on the actual ETF export stuff?
18:50:52 <altrus> :-p
18:51:24 <warlord> Sorry, I barely have time to answer questions here let alone code for gnucash these days.
19:05:27 *** warlord has quit IRC
19:19:30 *** ErKa has quit IRC
19:38:11 *** altrus has quit IRC
21:08:48 *** CDB-Man has joined #gnucash
21:09:26 *** bozonius has quit IRC
21:09:35 *** CDB-Man_ has quit IRC
21:09:40 *** bozonius has joined #gnucash
21:26:13 *** warlord has joined #gnucash
21:26:14 *** gncbot sets mode: +o warlord