Send gnucash-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnucash.org/mailman/listinfo/gnucash-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of gnucash-user digest..."
Today's Topics:
1. Re: Change text color (Adrien Monteleone)
2. Re: Post invoice still wants to be paid (dlbonline)
(Geert Janssens)
3. Re: Post invoice still wants to be paid (Geert Janssens)
4. Re: Post invoice still wants to be paid (Geert Janssens)
5. Re: Post invoice still wants to be paid (Geert Janssens)
6. Re: survey: unifying the appearance in different options
dialogs (Geert Janssens)
7. Re: Post invoice still wants to be paid (David Briggs)
8. Re: Closing and reopening Gnucash (Cheryl Wheeler)
9. When changing to different version of GNUcash what should be
done with data base or files? (aeneas)
10. Re: When changing to different version of GNUcash what
should be done with data base or files? (Geert Janssens)
11. Re: Post invoice still wants to be paid (dlbonline)
(Adrien Monteleone)
12. Re: Post invoice still wants to be paid (Adrien Monteleone)
13. Re: Post invoice still wants to be paid (Adrien Monteleone)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 Aug 2018 01:07:21 -0500
From: Adrien Monteleone <[email protected]>
To: gnucash-user <[email protected]>
Subject: Re: [GNC] Change text color
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I managed to get the inspector running on MacOS. Wow, this is way different
than 3.18.
So, try this:
#account_tree button
#account_tree header button
also
#account_tree label
#account_tree header label
Note, I discovered that font/letter rules don?t work on the buttons, only on
the labels. (but you *can* set the foreground color with ?color:? on the
buttons however)
I haven?t figured it all out yet, but it seems all of the buttons (and labels)
are children of ?#account_tree header'. So the descendent style works either
way. (with or without specifying ?header?) And there are no other pertinent
button or label descendants to get messy. (at least not for now)
#account_tree
simply styles the rest of the page, but I?ve found that the letter-spacing rule
doesn?t work there. (it does work on the header labels)
Though these do (in addition to the background-color and color):
font-family
font-size
font-weight
Note, there is also this:
.GncAccountPage
which styles the area of the sheet above the header around (and behind) the
totals button bar.
Note, you could subsitute .GncTreeView for #account_tree as that class is also
assigned to this widget, but it might also be assigned to other widgets used on
other tabs. So if you want to stay safe, stick with the ID #account_tree.
Regards,
Adrien
On Jul 31, 2018, at 11:44 PM, GT-I9070 H <[email protected]> wrote:
Em ter, 31 de jul de 2018 ?s 23:01, John Ralls <[email protected]> escreveu:
It?s missing the colon (?:?) between account_tree and column-header. That could
be a typo in the email rather than in gtk.css, of course.
Regards,
John Ralls
Thanks John,
It was not a typo in the email, I copied and pasted.
I tested
#account_tree:column-header {
color: lime;
}
and it did not work on Windows.
PS: For some reason your email dropped into my span folder.
Regards
GTI
------------------------------
Message: 2
Date: Wed, 01 Aug 2018 10:47:20 +0200
From: Geert Janssens <[email protected]>
To: [email protected], Colin Whyles <[email protected]>
Subject: Re: [GNC] Post invoice still wants to be paid (dlbonline)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Op dinsdag 31 juli 2018 18:44:53 CEST schreef Colin Whyles via gnucash-user:
I?ve had this problem and following the advice has fixed it, but you are
correct, there is sometimes no ?Assign As Payment? but there is an ?Edit
Payment? and you can do it from there.
Starting with 3,x if there is an "Edit Payment" that means gnucash believes
the payment is already related to a vendor/customer/employee in some way
(either directly linked to an invoice or retained as pre-payment) and using
this will open the payment dialog with this payment prepopulated so you can
adjust it (or assign to an invoice).
Assign as payment will only appear if the split on which you click is not
linked to any invoice or vendor/customer/employee and allows you to use a
transaction
To clarify:
1. When you go to: Actions > View Lots with the A/R account register open,
those invoices show ?open? in the ?closed? column and each only have the
one split for the invoice with no payment splits? (closed invoices will
have the date they were closed in that column instead)
2. ALL other invoices show their proper invoice and payment splits
everything dated correctly and the payment splits balance out the invoice
split for each?
3. There are no payment lots all by themselves in the upper right ?Lots in
Account? pane? (listed as their own row along with the invoice lots)
FYI for any such lots, gnucash knows or at least assumes the splits in these
lots belong to a certain customer, but not yet to an invoice. If you would
right-click on such a split directly in the A/R account register you would see
the "Edit Payment,,," menu option.
4. There is nothing at all in the bottom left, ?Splits free? pane.
FYI if there are splits here, that means there are splits in the A/R register
for which gnucash believes they are not related to any customer (yet). If you
would right-click on such a split directly in the A/R account register you
would see the "Assign as payment..." menu option.
Regards,
Geert
------------------------------
Message: 3
Date: Wed, 01 Aug 2018 10:56:28 +0200
From: Geert Janssens <[email protected]>
To: [email protected]
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Op dinsdag 31 juli 2018 19:02:07 CEST schreef Adrien Monteleone:
David,
Sorry, just saw this after sending.
Since it says ?Edit Payment? that probably means it is mis-assigned rather
than not-assigned. (but to what other bill is a guess since the other bills
don?t show it assigned to them, it might be a case of the payment thinks it
is assigned, but the bill doesn?t)
It is not mis-assigned. It's assigned. The confusion stems from the assumption
that a valid payment (in gnucash internal logic that is) is always assigned to
a bill. However it can equally be assigned to a vendor as a pre-payment.
As soon as gnucash knows who the payment was assigned to it's a valid business
payment so if you want to assign it to a bill later on you are effectively
editing it, hence the "Edit Payment..." menu option.
Geert
------------------------------
Message: 4
Date: Wed, 01 Aug 2018 11:17:32 +0200
From: Geert Janssens <[email protected]>
To: [email protected]
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Op dinsdag 31 juli 2018 18:59:07 CEST schreef Adrien Monteleone:
1. Find and select the transaction for the payment.
2. Right-click the transaction and choose ?Assign as payment...?
3. This brings up the Process Payment dialog.
4. Select the bill, be *careful* to make sure the payment amount, payment
date and Num are all correct. (GC has a tendency to set the date as today,
rather than the original transaction date so you might have to change it,
as well as re-enter the transaction/check #)
This should no longer be an issue if you edit an existing payment. I have just
tried this and in all cases the payment date is preserved.
A slight variation of this second method is to,
1. Choose Process Payment from the Business > Vendor menu
2. Enter the vendor, you?ll see all outstanding bills and unassigned (pre)
payments. 3. Simply select both the invoice and the payment, be sure the
date, amount and Num/Memo details are all correct, double check the account
to credit (usually checking or cash) and click OK.
Even in this case the date and Num/Memo details are preserved although it's
less obvious in the payment dialog. Each pre-existing payment that you select
from the list will retain its num and memo information. Only if the final
transaction would result in an additional payment transaction (which can
happen if the balance of all selected payments and invoices in the list is not
0) the values of the num and memo field are used for the new payment
transaction.
On a side note, it appears you are either using a custom A/P account or
renamed the original A/P account. I?m not sure about renaming, but custom
A/P accounts might not always work well with the Business Features.
(perhaps this was the original cause of the dissociation - renaming the
account) One of the more seasoned users or developers would need to advise
on this point. You can certainly have an ?Other A/P? account(s) and even
make them children of the main A/P account that you manually make entries
to, but the Business Features are really looking for only one account in
the tree of type A/P and with the name Accounts Payable. (same goes for
receivables) And you should rarely if never manually edit transactions in
either of the default A/R or A/P accounts.
I don't know for sure if parts of gnucash will have issues with multiple A/P
accounts. I don't think so as we have always supported this for multi-currency
situations. However several reports are not geared towards handling with
multiple A/P accounts at once. Several reports will only show results based on
one A/P at the time. So see results from another A/P one would have to adjust
the report settings to see that A/P. But it's not possible to report on two
A/P accounts together in a single report.
In general there should be no need to have multiple A/P accounts and in many
cases the motivations to create multiple A/P accounts come from a
misunderstanding of how accounting works.
For full disclosure I'll note for my own company I have two A/P accounts on
request of my accountant. So it does happen... The motivation here is that my
company has two distinct activities with different tax rules and the
accountant wants to track these separately. For unrelated reasons I'm no
longer tracking this company in gnucash though so I don't know if all the
obscure corners of gnucash can handle it properly.
Regards,
Geert
------------------------------
Message: 5
Date: Wed, 01 Aug 2018 11:23:26 +0200
From: Geert Janssens <[email protected]>
To: [email protected]
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Op dinsdag 31 juli 2018 19:43:41 CEST schreef Adrien Monteleone:
You?re welcome.
It took me lots of web searching and stumbling on some old pages describing
Lots and the Business Features. (from the days when they were being planned
and first coded)
I don?t know that there is a definitive wiki page on this yet for this
purpose. (there is however a good Lots page for investments)
I had sent a reply yesterday with the relevant wiki link but apparently it
didn't make it to the list.
Here's the link again:
https://wiki.gnucash.org/wiki/Business_Features_Issues
I double-checked the sent mail. It was to the correct address, but somehow
didn't arrive anyway.
Geert
------------------------------
Message: 6
Date: Wed, 01 Aug 2018 11:57:06 +0200
From: Geert Janssens <[email protected]>
To: Di Mang <[email protected]>
Cc: Gnucash Users <[email protected]>
Subject: Re: [GNC] survey: unifying the appearance in different
options dialogs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Op dinsdag 31 juli 2018 00:51:54 CEST schreef Di Mang:
Hello Geert and Adrien,
I agree it is a good idea to revise the report options and possibly
summarize to reduce the number of tabs.
There are currently
some reports that have tabs with only a few settings.
But in my opinion it would not be a good solution to move away completely
from tabs for *all* option dialogs.
For option dialogs with only a few reports it will take up too much space
on the window.
This doesn't make sense to me. If we move to "tabs" on the left for at least
one option window, we need to dimension the window anyway that it will fit on
the smallest screen we wish to support. How would this minimal dimension be
affected by the number of "tabs" in that area ? (I'm quoting "tabs" because
it's not the exact term for the exact widget I had in mind, more on that
below).
Having a consistent way to represent options throughout the application is
more important to me.
I think we
have to
distinguish between different
option
dialogs / windows:
* main window: an exception, because of dynamic tabs (with a scroll bar if
necessary)
Indeed, although a scroll bar for tabs is a bit awkward.
*
windows with main preferences: currently with tabs on the left side (like
in Geany)
I suppose you mean "many" preferences.
An alternative solution may be
the Side Bar List instead of Tabs on the left side (like in LibreOffice,
Gimp, Firefox)
I surely agree a Side Bar List is better and that (or something similar) is
what I had in mind. In fact I thought that's what you meant as well as the
option dialogs for several reports were showing a list of groups instead as a
list of tabs on my system already before your change.
* option dialogs with only few tabs: tabs at the top position (like in
Geany, Gedit, Gimp, LibreOffice)
As said that would then break consistency again. Wasn't that your initial
argument (which I like) ?
My ideal solution would be a dynamic side bar list. That is if there's enough
horizontal screen space (and the dialog is wide enough) show the list
permanently. If the dialog gets narrowed (either due to user action or due to
limited screen space), make the list hidden by default (with a button to show
it) and when that button is clicked make it hover the actual content.
Here's a video of another application implementing this behavior (though from
the KDE world):
https://www.youtube.com/watch?v=H24jdjE5Q6E
Clearly this is for gnucash 4.x at best...
Regards,
Geert
------------------------------
Message: 7
Date: Mon, 30 Jul 2018 18:13:15 -0500
From: "David Briggs" <[email protected]>
To: "'David Cousens'" <[email protected]>,
<[email protected]>
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
David,
Actually, I misled you in my original post (due to my novice standing with the
community). The document in question is actually a vendor bill (I now
understand the difference between a bill and an invoice). However, I think you
information below would still apply.
I will continue to hunt for a solution, other than starting over on my database
to get rid of this issue. There should be a better way.
Thanks for your help.
David Briggs
[email protected] <mailto:[email protected]>
918 625 9170
From: David Cousens [mailto:[email protected]]
Sent: Monday, July 30, 2018 5:52 PM
To: David Briggs <[email protected]>; [email protected]
Subject: Re: [GNC] Post invoice still wants to be paid
David,
I honestly don't know how an unposted invoice appears in the XML file. By default,
the XML file is stored in a gzipped state. If you edit the preferences in the General
tab there is a checkbox for Compress files. Unselect that and File->Save or ->
SaveAs to get the uncompressed version. I have opened an uncompressed version of a
test file I use for investigating how GnuCash functions.
If you search for the tag <gnc:GncInvoice version="2.0.0"> you can locate the invoice
records between that and the </gnc:GncInvoice> tag.
If it is posted there will be a tag
<invoice:posted>
<ts:date>2018-07-20 00:00:00 +1000</ts:date>
</invoice:posted>
within that structure.
There does not appear to be a link from this record to a payment - that is
possibly elsewhere in the file . The invoice does contain links to the guid for
the post transaction which may allow you to identify the payment transaction.
It may not simply be a matter of changing that entry however to post and unpost
an invoice as that action may also affect records elsewhere in the structure of
the book. If you do attempt to edit it, keep an original copy you can restore.
I would only use this to identify the invoice numbers, tag
<invoice:id>000003</invoice:id>, for any invoices you think are a problem in the XML
file and then use the Business->Customer->Find Invoice dialog to pull them up and make any
modifications within GnuCash. If the payment has become separated , it is possibly easiest to
delete the payment transaction and then unpost the invoice, repost it and enter the payment
details using the Process Payment entry to assign the payment to the specific invoice. One of the
main developers may be able to provided more help.
Hope this helps
David Cousens
------------------------------
Message: 8
Date: Tue, 31 Jul 2018 10:20:59 -0400
From: Cheryl Wheeler <[email protected]>
To: [email protected]
Subject: Re: [GNC] Closing and reopening Gnucash
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Richard,
It sounds as though you may be opening the latest backup file instead of
your main data file. The data file should be named something like
RichardsData.gnucash (or whatever you named it). The backup filenames
will contain strings of numbers, which are date stamps indicating when
they were saved, something like RichardsData.gnucash.20180731154137.gnucash.
If that is what you have been doing, then probably your original data
file does not have all of your data, because you have been saving new
data into your backup files. I suggest the following:
?- open your last-opened file (as Adrien says, you can do that just by
launching the GnuCash application)
?- use the menu options File -> Save As to save the file under the
original data filename
?- in future, open the file with that original filename.gnucash only,
unless you know that you need to do something with a backup file for
some reason. You can do this by launching GnuCash, which will open the
last-opened data file automatically.
?- to reduce confusion, you may want to delete some of your old backup
files, and maybe limit the number of days that they are saved, if you
haven't already done that.
Hope that helps.
Date: Mon, 30 Jul 2018 19:53:49 -0400
From: Richard Barmann<[email protected]>
To:[email protected]
Subject: [GNC] Closing and reopening Gnucash
Message-ID:<[email protected]>
Content-Type: text/plain; charset=utf-8
When I want to reopen Gnucash the next day I have to scroll through the
files to try to pick out the latest file. T trid closing with the Quit
at the bottom of the page and also tried to Save as but they always have
to scroll through to open the latest file. Some of the files names are
so long that I cannot tell if they are log fills. and I have to guess
until I find the last one.
Thank you for any help as this is a time killer when I am in a hurry.
------------------------------
Message: 9
Date: Tue, 31 Jul 2018 21:58:48 -0500 (CDT)
From: aeneas <[email protected]>
To: [email protected]
Subject: [GNC] When changing to different version of GNUcash what
should be done with data base or files?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
It seems that there always exists a possibility that data base/file
structures can change from one version to another of GNUcash. Generally
speaking developers try to consider this and may make accommodation for some
older versions in newer versions of their software which means there is a
chance that newer versions of the software will function properly when using
data bases/files produced by older versions. However, when needing to
migrate backward from a newer version to an older version this is likely to
be more problematic. The nature of the data bases/files that GNUcash is
producing is such that failure to do this properly risks the creation of
serious problems when making such migrations. This owes to the notion both
that the data consists of financial records as well as the idea that a large
amount of data accumulated over a long period of time may be involved.
Therefore it would seem that changing the version of GNUcash is something
that needs to be done carefully. This should include some means to verify
success in a short amount of time insofar as it doesn't take long before the
idea of returning to a prior state known to be good can become extremely
difficult if not impossible.
Is there a procedure that ought to be followed when making such a change?
What is the possibility that these considerations differ based on the chosen
output format?
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
------------------------------
Message: 10
Date: Wed, 01 Aug 2018 12:59:40 +0200
From: Geert Janssens <[email protected]>
To: [email protected]
Cc: aeneas <[email protected]>
Subject: Re: [GNC] When changing to different version of GNUcash what
should be done with data base or files?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Op woensdag 1 augustus 2018 04:58:48 CEST schreef aeneas:
It seems that there always exists a possibility that data base/file
structures can change from one version to another of GNUcash. Generally
speaking developers try to consider this and may make accommodation for some
older versions in newer versions of their software which means there is a
chance that newer versions of the software will function properly when
using data bases/files produced by older versions. However, when needing
to migrate backward from a newer version to an older version this is likely
to be more problematic. The nature of the data bases/files that GNUcash is
producing is such that failure to do this properly risks the creation of
serious problems when making such migrations. This owes to the notion both
that the data consists of financial records as well as the idea that a
large amount of data accumulated over a long period of time may be
involved.
Therefore it would seem that changing the version of GNUcash is something
that needs to be done carefully. This should include some means to verify
success in a short amount of time insofar as it doesn't take long before the
idea of returning to a prior state known to be good can become extremely
difficult if not impossible.
Is there a procedure that ought to be followed when making such a change?
What is the possibility that these considerations differ based on the chosen
output format?
Gnucash tries very hard to provide a backwards compatible return path the the
last version of a previous release.
So if you tried 3.x and it has bugs you can't work around acceptably, you
should be able to return to 2.6.21 in this case.
However while this is tested, it's unfortunately impossible for the developers
to test all possible scenarios so even this may fail in some cases.
For that reason it's important you create a backup of your data file/database
before trying a new version, You may want to do the same for the metadata
stored in .gnucash for 2.6.x. That will be your known good state in worst case
and it is very easy to return to it (not extremely difficult or impossible at
all).
You can consult the gnucash FAQ for more information on which files to back
up.
https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_backup_my_data.3F
https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_backup_my_GC_environment.
2C_including_preferences.3F
Regards,
Geert
------------------------------
Message: 11
Date: Wed, 1 Aug 2018 06:40:50 -0500
From: Adrien Monteleone <[email protected]>
To: gnucash-user <[email protected]>
Subject: Re: [GNC] Post invoice still wants to be paid (dlbonline)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Thanks Geert,
That removes most of the cases to use the Lots window to fix things and
certainly makes life much simpler.
Of course, that last part works well, but only if, those free splits are
properly free and aren?t the result of a mess of miss-applied payments or a
portion of a payment broken up that shouldn?t have been. Unfortunately, when I
usually have free splits in this pane, it?s always been such a mess that
requires re-assigning a chain of several payments and recombining errantly
split payments. I haven?t been so lucky to have such splits be simply whole
payments that just need to be assigned.
Regards,
Adrien
On Aug 1, 2018, at 3:47 AM, Geert Janssens <[email protected]> wrote:
Op dinsdag 31 juli 2018 18:44:53 CEST schreef Colin Whyles via gnucash-user:
I?ve had this problem and following the advice has fixed it, but you are
correct, there is sometimes no ?Assign As Payment? but there is an ?Edit
Payment? and you can do it from there.
Starting with 3,x if there is an "Edit Payment" that means gnucash believes
the payment is already related to a vendor/customer/employee in some way
(either directly linked to an invoice or retained as pre-payment) and using
this will open the payment dialog with this payment prepopulated so you can
adjust it (or assign to an invoice).
Assign as payment will only appear if the split on which you click is not
linked to any invoice or vendor/customer/employee and allows you to use a
transaction
To clarify:
1. When you go to: Actions > View Lots with the A/R account register open,
those invoices show ?open? in the ?closed? column and each only have the
one split for the invoice with no payment splits? (closed invoices will
have the date they were closed in that column instead)
2. ALL other invoices show their proper invoice and payment splits
everything dated correctly and the payment splits balance out the invoice
split for each?
3. There are no payment lots all by themselves in the upper right ?Lots in
Account? pane? (listed as their own row along with the invoice lots)
FYI for any such lots, gnucash knows or at least assumes the splits in these
lots belong to a certain customer, but not yet to an invoice. If you would
right-click on such a split directly in the A/R account register you would see
the "Edit Payment,,," menu option.
4. There is nothing at all in the bottom left, ?Splits free? pane.
FYI if there are splits here, that means there are splits in the A/R register
for which gnucash believes they are not related to any customer (yet). If you
would right-click on such a split directly in the A/R account register you
would see the "Assign as payment..." menu option.
Regards,
Geert
_______________________________________________
gnucash-user mailing list
[email protected]
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.
------------------------------
Message: 12
Date: Wed, 1 Aug 2018 06:42:37 -0500
From: Adrien Monteleone <[email protected]>
To: gnucash-user <[email protected]>
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Makes sense of course.
So ?Assign? should really only appear for a manually entered payment in a
register. (or something imported)
Regards,
Adrien
On Aug 1, 2018, at 3:56 AM, Geert Janssens <[email protected]> wrote:
Op dinsdag 31 juli 2018 19:02:07 CEST schreef Adrien Monteleone:
David,
Sorry, just saw this after sending.
Since it says ?Edit Payment? that probably means it is mis-assigned rather
than not-assigned. (but to what other bill is a guess since the other bills
don?t show it assigned to them, it might be a case of the payment thinks it
is assigned, but the bill doesn?t)
It is not mis-assigned. It's assigned. The confusion stems from the assumption
that a valid payment (in gnucash internal logic that is) is always assigned to
a bill. However it can equally be assigned to a vendor as a pre-payment.
As soon as gnucash knows who the payment was assigned to it's a valid business
payment so if you want to assign it to a bill later on you are effectively
editing it, hence the "Edit Payment..." menu option.
Geert
------------------------------
Message: 13
Date: Wed, 1 Aug 2018 06:48:38 -0500
From: Adrien Monteleone <[email protected]>
To: gnucash-user <[email protected]>
Subject: Re: [GNC] Post invoice still wants to be paid
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Aug 1, 2018, at 4:17 AM, Geert Janssens <[email protected]> wrote:
Op dinsdag 31 juli 2018 18:59:07 CEST schreef Adrien Monteleone:
1. Find and select the transaction for the payment.
2. Right-click the transaction and choose ?Assign as payment...?
3. This brings up the Process Payment dialog.
4. Select the bill, be *careful* to make sure the payment amount, payment
date and Num are all correct. (GC has a tendency to set the date as today,
rather than the original transaction date so you might have to change it,
as well as re-enter the transaction/check #)
This should no longer be an issue if you edit an existing payment. I have just
tried this and in all cases the payment date is preserved.
I just happen to be doing some cleanup and had a case of unposting & reposting
and needing to re-assign the payment. And it used 7/31/18 as the date instead of
the original payment date. (I was selecting a single bill and single payment for
equal amounts) The Num field was also blank and had to be re-filled.
A slight variation of this second method is to,
1. Choose Process Payment from the Business > Vendor menu
2. Enter the vendor, you?ll see all outstanding bills and unassigned (pre)
payments. 3. Simply select both the invoice and the payment, be sure the
date, amount and Num/Memo details are all correct, double check the account
to credit (usually checking or cash) and click OK.
Even in this case the date and Num/Memo details are preserved although it's
less obvious in the payment dialog. Each pre-existing payment that you select
from the list will retain its num and memo information. Only if the final
transaction would result in an additional payment transaction (which can
happen if the balance of all selected payments and invoices in the list is not
0) the values of the num and memo field are used for the new payment
transaction.
In the above recent case, I didn?t chance it. But that is re-assuring.
On a side note, it appears you are either using a custom A/P account or
renamed the original A/P account. I?m not sure about renaming, but custom
A/P accounts might not always work well with the Business Features.
(perhaps this was the original cause of the dissociation - renaming the
account) One of the more seasoned users or developers would need to advise
on this point. You can certainly have an ?Other A/P? account(s) and even
make them children of the main A/P account that you manually make entries
to, but the Business Features are really looking for only one account in
the tree of type A/P and with the name Accounts Payable. (same goes for
receivables) And you should rarely if never manually edit transactions in
either of the default A/R or A/P accounts.
I don't know for sure if parts of gnucash will have issues with multiple A/P
accounts. I don't think so as we have always supported this for multi-currency
situations. However several reports are not geared towards handling with
multiple A/P accounts at once. Several reports will only show results based on
one A/P at the time. So see results from another A/P one would have to adjust
the report settings to see that A/P. But it's not possible to report on two
A/P accounts together in a single report.
In general there should be no need to have multiple A/P accounts and in many
cases the motivations to create multiple A/P accounts come from a
misunderstanding of how accounting works.
For full disclosure I'll note for my own company I have two A/P accounts on
request of my accountant. So it does happen... The motivation here is that my
company has two distinct activities with different tax rules and the
accountant wants to track these separately. For unrelated reasons I'm no
longer tracking this company in gnucash though so I don't know if all the
obscure corners of gnucash can handle it properly.
Good to know. I forgot about multi-currency. I know I had run into some issues
with trying this in the past and getting the business features to post
properly. But in my case, I really shouldn?t have had a separate account anyway.
Regards,
Adrien
Regards,
Geert
------------------------------
Subject: Digest Footer
_______________________________________________
gnucash-user mailing list
[email protected]
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.
------------------------------
End of gnucash-user Digest, Vol 185, Issue 4
********************************************
