2016-01-10 GnuCash IRC logs
01:06:04 *** pragomer1 has joined #gnucash
01:07:41 <pragomer1> how can I define a default booking account for lets say a special outgoing account?
01:58:38 *** pragomer1 has quit IRC
02:30:42 *** fell has quit IRC
02:45:06 *** Mechtilde has joined #gnucash
05:35:35 *** autoditac__ has joined #gnucash
06:29:18 *** fabior has joined #gnucash
07:23:24 *** fabior has quit IRC
07:24:14 *** rubdos has joined #gnucash
08:21:28 *** Tropicalrambler has joined #gnucash
08:21:36 *** jonian has joined #gnucash
08:36:44 *** Tropicalrambler has quit IRC
09:00:10 *** Jimraehl1 has joined #gnucash
09:23:15 *** fell has joined #gnucash
09:23:15 *** gncbot sets mode: +o fell
09:23:33 *** himaxx has joined #gnucash
09:28:14 *** himaxx has quit IRC
09:40:59 <jonian> Hello there!
09:41:00 <jonian> I have been using Gnucash since about 2010 for personal finance and it's been a great tool!
09:41:01 <jonian> The documentation is also really good, so this is the first time I am actually looking for something I haven't managed to find on my own so I thought i would give IRC a try.
09:41:02 <jonian> What I would like to do is the equivalent of 'copy/pasting' transactions between two different gnucash files.
09:41:04 <jonian> I tried "File->Export Transactions to CSV..." on the source file, and "File->Import Transactions from CSV..." on the destination file, but they don't seem to have been designed to work together... or maybe it's me who doesn't understand it.
09:41:05 <jonian> Do you have any tips, or can point me to any guides on how this "Import Transactions from CSV..." works?
09:41:25 <jonian> or if there is any better way to achieve what I am trying to do...
09:41:42 <jonian> I would be very thankful to know!
09:46:25 <Mechtilde> do you use the samen gnucash version on both sides?
09:48:21 <jonian> now i tried on my pc
09:48:30 <jonian> so yes
09:49:32 <jonian> but I am interested to do this on two different computers eventually... but I can have the same version on both sides if needed. This is just a one-off thing
09:54:48 <jonian> When you use the "Export transactions from CSV...", the CSV file looks very much like the account register (i believe it is called), just comma-separated, which is great.
09:56:41 <jonian> But the "Import transactions from CSV..." asks me to specify the type of each column, although they are specified in the first row of the file.
09:57:50 <jonian> The problem is that in the drop-down menus for the column types you can't find all the columns present in the CSV file
09:59:12 <jonian> which makes me suspect the "Import from CSV..." is made for importing some bank balance file, but not from the Gnucash exported CSV, please correct me if I'm wrong.
09:59:31 *** aqua___ has joined #gnucash
10:03:08 *** aqua___ has quit IRC
10:17:33 *** aqua___ has joined #gnucash
10:20:58 <fell> jonian, IMHO you should file a bug report "Gnucash should be able to import all fields, which it exports" or similar.
10:42:24 <jonian> thank you fell! Interesting, so you do think they are designed to work together.
10:43:21 <jonian> I just registered on the bugzilla site, so I will try to do that a bit later.
10:45:15 <jonian> It would be interesting to read something more about this "Import from CSV..." how it is supposed to work, I use the "Import QIF..." usually and I found much more info about it in the FAQ, but not so much about the CSV one
10:50:17 *** MarcGuay has quit IRC
10:51:02 <jonian> g2g now, but I will be staying in the channel in case someone has any more input
10:51:04 <jonian> cheers!
10:55:37 *** aqua___ has quit IRC
11:06:05 *** MarcGuay has joined #gnucash
11:30:41 <mikee> jralls: I was about to commit a fix to https://bugzilla.gnome.org/show_bug.cgi?id=760398 and I see you are going to do new realease tomorrow.
11:31:17 <mikee> I'd just like to ensure someone else does an independent test of the fix before release.
12:16:15 *** mikee is now known as mikee_afk
12:16:30 *** mikee_afk is now known as mikee-afk
13:08:18 <jralls> mikee: Do you want to hold off pushing the commit until after I tag the release or do you want me to test your fix?
13:10:39 <jralls> I notice that you left a question on the bug. gjanssens isn't not around much, but maybe warlord has an opinion: The question is "is there ever a situation where an invoice number should be duplicated?"
13:11:31 <Mechtilde> I don't know one
13:14:10 <Mechtilde> in Germany you have to explain very good why you have a double invoice number to the tax gov
13:14:15 <Mechtilde> or similar
13:17:25 <jralls> In the US invoices are just between you and your customer or vendor, they're not tax documents. But ISTM from an accounting controls POV it would still be bad practice to allow different invoices to have the same number.
13:19:09 <Mechtilde> In Germany all invoices to your customers must have an unique invoice ID since some years
13:19:20 <Mechtilde> around 8 or ten
13:37:19 *** ArtGravity has joined #gnucash
13:39:14 <ArtGravity> I recently updated the description in all of my bill terms to reflect a change in the interest rate for late payment, but the old rate is still appearing on invoices. Any idea what I may have missed?
13:43:05 <Mechtilde> why bill terms?
13:43:17 <Mechtilde> invoice != bill
13:44:54 <ArtGravity> Business/Billing Terms Editor is where you set your billing terms for your invoices
13:44:56 <warlord> jralls: I cannot think of any time it should be duplicated.
13:47:59 <jralls> OK. So we just need mikee-afk to push his change...
13:48:18 <warlord> Ok
13:49:00 <Mechtilde> ArtGravity, did you restart GnuCash?
13:49:21 <ArtGravity> Yes. The change was made some days ago.
13:49:49 <Mechtilde> and you add the new billing term
13:50:06 <ArtGravity> No new Billing Term
13:50:18 <ArtGravity> It's and edit to the description field of all existing terms
13:50:59 <ArtGravity> The text "1%" was replaced with the text "1.5%"
13:51:40 <ArtGravity> Checking the terms shows the new value is present.
13:52:18 <ArtGravity> Choosing printable invoice still displays the old "1%" value instead of the expected "1.5%" text.
13:55:26 <Mechtilde> is it a new invoice?
13:56:25 <ArtGravity> At least one is.
13:57:14 <ArtGravity> I have two that I am expecting to see the new terms on, and I don't recall if the first was generated before or after the change, but the latter definitely was.
13:58:02 <ArtGravity> The first has been unposted and reposted to adjust the post/due date from 2015 to 2016, so I would expect both to have the new terms, but neither is showing it.
13:58:27 <Mechtilde> do you choose the new entry when you create the invoice
13:58:39 <ArtGravity> What new entry?
13:58:44 <ArtGravity> There is no new entry.
13:58:55 <Mechtilde> or changed entry of the billing term
14:00:47 <ArtGravity> Looking at the more recent invoice, I notice that it had no term set, so I just reposted it with the correct term. It still show the wrong text.
14:02:24 <Mechtilde> http://code.gnucash.org/docs/C/gnucash-guide/bus-ar-invoices1.html unter 13.4.1 the images show "Terms - 30 Days"
14:02:36 <Mechtilde> do you see there the changed text?
14:03:01 <Mechtilde> or on the next image in the middle line 4
14:03:02 <ArtGravity> You only see the name of the term there, and I did not change the name.
14:03:46 <Mechtilde> only the description?
14:04:00 <ArtGravity> To the first question, that won't change, as I have not changed the term names.
14:04:25 <ArtGravity> To the second question, that is the invoice description field, not the billing terms description field.
14:04:39 <ArtGravity> The invoice description field appears on the customer report, not the invoice.
14:04:57 <ArtGravity> That is not what I am trying to adjust. That part is working fine.
14:05:40 <ArtGravity> If you go to the next image on the same page, you can see the text above the table. That is what I expect to see change.
14:06:11 <Mechtilde> beginning with terms?
14:07:07 <Mechtilde> this isn't the description but the name of the name of the Terms
14:07:14 <ArtGravity> Yes
14:07:29 <ArtGravity> I have no Reference field on my invoices
14:07:41 <Mechtilde> s/of the name//
14:07:43 <ArtGravity> I do show a Terms section
14:08:10 <ArtGravity> That is what isn't updating to reflect the new content
14:08:50 <Mechtilde> http://code.gnucash.org/docs/C/gnucash-guide/bus-setupterms.html
14:09:30 <ArtGravity> Correct
14:09:56 <ArtGravity> In the Term Definition section, I have made changes to Description that are not being reflected on new invoices
14:10:53 <Mechtilde> for me it works
14:11:12 <Mechtilde> i tested it with version 2.6.9 in German
14:11:52 <ArtGravity> 2.6.9 English with MySQL backend here
14:13:10 <ArtGravity> This looks like it may have to do with the parent/child relationships
14:14:08 <ArtGravity> In the billterms table I show 5 different entires named "On Receipt"
14:14:30 <ArtGravity> Only one has the 1.5% text
14:15:27 <Mechtilde> and another point
14:15:48 <Mechtilde> you know that is for discount for early payment
14:15:56 <ArtGravity> what?
14:15:58 <ArtGravity> It's text
14:16:07 <ArtGravity> I'm not filling in the discount field
14:16:21 <ArtGravity> Not on an On Receipt term
14:17:03 <ArtGravity> On Receipt is always the full amount due on the day invoiced, so the discount fields and day fields are all set to zero
14:18:00 <ArtGravity> I can fix this from the MySQL side now that I see the problem. I just wish I knew why it wasn't working from the application.
14:20:35 <Mechtilde> and why don't you use a new entry?
14:20:56 <ArtGravity> Why would I want a new entry to clutter my terms?
14:21:20 <Mechtilde> may be you can't change an entry if you have post the invoice
14:21:21 <ArtGravity> Then I would have to be able to identify which On Receipt term to use
14:21:56 <ArtGravity> I want to change my late payment interest rate on all my existing terms, not any of the actual terms themselves.
14:25:23 <Mechtilde> then you change the contract of the existing invoices
14:25:33 <Mechtilde> and the content
14:25:46 <ArtGravity> That's fine. They are all paid anyway
14:26:11 <ArtGravity> Before they were paid, they were either printed to PDF or paper
14:27:12 <ArtGravity> Updating the description fields in MySQL has fixed the problem as far as my needs go.
14:27:51 <ArtGravity> Ideally one doesn't want to have to use the late payment penalty provision, but it needs to be on the invoices just in case.
14:30:11 <Mechtilde> I hope for you that the gov in your country has no interest to compare the printed invoices with the software configuration
14:30:57 <ArtGravity> So what if they did?
14:31:11 <ArtGravity> The invoiced and paid amounts still all match.
14:32:04 <Mechtilde> If you can change such data the accounting isn't save enough
14:32:36 <ArtGravity> Then no accounting is safe.
14:32:46 <Mechtilde> the integrity
14:32:51 <ArtGravity> For whatever safe is supposed to mean in accounting
14:32:53 <Mechtilde> of the data
14:34:30 <ArtGravity> Right, can't have the silent partner that contributes nothing but barriers to the success of the business worried that he may not be getting a large enough cut.
14:35:12 <ArtGravity> My invoice are showing the correct late payment penalties now, so I will take my leave.
14:35:13 *** ArtGravity has left #gnucash
14:37:37 *** aqua___ has joined #gnucash
14:43:13 *** aqua___ has quit IRC
15:13:04 *** CDB-Man_ has joined #gnucash
15:14:20 *** CDB-Man has quit IRC
15:14:28 *** rubdos has quit IRC
15:16:36 *** CDB-Man_ has quit IRC
15:17:06 *** CDB-Man has joined #gnucash
15:17:57 *** CDB-Man has quit IRC
15:18:06 *** CDB-Man has joined #gnucash
15:30:06 <linas> warlord, sorry I keep starting and getting distracted.
15:37:17 *** Mechtilde has quit IRC
15:43:28 *** fabior has joined #gnucash
15:51:52 *** fell_ has joined #gnucash
15:53:41 *** fell has quit IRC
15:55:25 <linas> warlord, OK, I stubbed out the AAAA records
15:55:45 <linas> Its got a 3-day expiry though so it may take a while to percolate.
15:56:44 <linas> dig -t ANY svn.gnucash.org shows fly-by-night.ihtfp.org. 85564 IN AAAA 2001:4830:143:1::fb9
15:56:44 <linas> warlord
16:19:38 *** jonian has quit IRC
16:23:14 *** fabior has quit IRC
16:24:28 *** autoditac__ has quit IRC
16:28:58 *** autoditac__ has joined #gnucash
16:45:00 *** autoditac__ has quit IRC
17:09:35 *** mikee-afk is now known as mikee_afk
17:09:42 *** mikee_afk is now known as mikee
17:10:05 <jralls> mikee-afk: I guess you've already gone to bed, so I'm going to tag the release and proceed. 760398 will have to wait until 2.6.12.
17:12:01 <mikee> jralls: Nope. Just got home and pushed the change.
17:12:30 <warlord> linas: okay.
17:12:32 <warlord> Thanks
17:14:11 *** warlord has quit IRC
17:17:30 <mikee> Revert if your not happy but I think this is the correct behaviour.
17:18:58 <mikee> '
17:21:04 <jralls> mikee: Do I need to test something, or are you happy with it? Also, did you the discussion earlier where Mechtilde and warlord agreed that there shouldn't be duplicate invoice numbers?
17:22:38 <mikee> jralls: Yes, saw that.
17:23:15 <mikee> A quick check would would help me sleep easy though.
17:23:45 <jralls> OK, what should I do?
17:24:13 <jralls> You can put it on the bug if it's too long for IRC...
17:25:54 <mikee> Just follow the bug steps in the bug.
17:31:35 <jralls> OK, building...
17:31:53 <mikee> All it does it to not assign the ID until the user OKs in the "new invoice" dialog. Which is the normal behviour when creating a new invoice.
17:41:54 <jralls> OK, Cancelling doesn't increment the Invoice #. Duplicate, OK makes 0000002, Duplicate, Cancel then Duplicate, OK makes 000003. That's what you want, right?
17:43:04 <mikee> Yes. Prevously cancelling incremented the counter.
17:43:28 <mikee> Which left gaps in the series.
17:44:51 <jralls> Very good then. You can sleep well. ;-)
17:45:52 <mikee> Thanks John, And so, to bed.
18:09:52 *** bozonius has joined #gnucash
18:56:36 *** gnomey has quit IRC
19:06:15 *** gnomey has joined #gnucash
19:57:17 *** mikee_ has joined #gnucash
19:58:25 *** mikee has quit IRC
19:58:25 *** mikee_ is now known as mikee
19:58:25 *** ChanServ sets mode: +o mikee