[GNC] Prevent autocopy in register

[Nigel]

I do a split transaction, calling it Shopping. There was potatoes, 
tomatoes and a pair of socks. Next time I do a split transaction and 
call it Shopping, the 3 items are duplicated. How do I prevent this, or 
remove all the duplicated, incorrect, items.

On 01/08/2018 13:48, gnucash-user-request at gnucash.org wrote:
> Send gnucash-user mailing list submissions to
> 	gnucash-user at gnucash.org
>
> 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
> 	gnucash-user-request at gnucash.org
>
> You can reach the person managing the list at
> 	gnucash-user-owner at gnucash.org
>
> 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 <adrien.monteleone at lusfiber.net>
> To: gnucash-user <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Change text color
> Message-ID: <23D5DEDD-3EAA-4BBD-BA82-3D0AA6AF9436 at lusfiber.net>
> 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 <gti9070h at gmail.com> wrote:
>>
>> Em ter, 31 de jul de 2018 ?s 23:01, John Ralls <jralls at ceridwen.us> 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 <geert.gnucash at kobaltwit.be>
> To: gnucash-user at gnucash.org, Colin Whyles <cwhyles at btinternet.com>
> Subject: Re: [GNC] Post invoice still wants to be paid (dlbonline)
> Message-ID: <2370574.A3vxbG4PBb at legolas.kobaltwit.lan>
> 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 <geert.gnucash at kobaltwit.be>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <26437655.dCDDeQmxtz at legolas.kobaltwit.lan>
> 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 <geert.gnucash at kobaltwit.be>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <2286080.ollJFK3Mvo at legolas.kobaltwit.lan>
> 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 <geert.gnucash at kobaltwit.be>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <1738952.IXbudanllS at legolas.kobaltwit.lan>
> 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 <geert.gnucash at kobaltwit.be>
> To: Di Mang <di.mang.freetime at gmail.com>
> Cc: Gnucash Users <gnucash-user at gnucash.org>
> Subject: Re: [GNC] survey: unifying the appearance in different
> 	options dialogs
> Message-ID: <1781156.0370kEhaNB at legolas.kobaltwit.lan>
> 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" <dlbriggs at cox.net>
> To: "'David Cousens'" <davidcousens at bigpond.com>,
> 	<gnucash-user at gnucash.org>
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <000201d4285a$e5c0ea20$b142be60$@cox.net>
> 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
>
> dlbriggs at cox.net <mailto:dlbriggs at cox.net>
>
> 918 625 9170
>
>   
>
> From: David Cousens [mailto:davidcousens at bigpond.com]
> Sent: Monday, July 30, 2018 5:52 PM
> To: David Briggs <dlbriggs at cox.net>; gnucash-user at gnucash.org
> 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 <c_wheeler_2002 at yahoo.ca>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Closing and reopening Gnucash
> Message-ID: <5f83e21a-aded-f93b-acb6-05d662ae09f8 at yahoo.ca>
> 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<dick at stripingthetown.com>
>> To:gnucash-user at gnucash.org
>> Subject: [GNC] Closing and reopening Gnucash
>> Message-ID:<0f4bf8dd-249c-75e6-84b2-9f201dc16ac7 at stripingthetown.com>
>> 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 <receiver at gowdygroup.net>
> To: gnucash-user at gnucash.org
> Subject: [GNC] When changing to different version of GNUcash what
> 	should be done with data base or files?
> Message-ID: <1533092328409-0.post at n4.nabble.com>
> 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 <geert.gnucash at kobaltwit.be>
> To: gnucash-user at gnucash.org
> Cc: aeneas <receiver at gowdygroup.net>
> Subject: Re: [GNC] When changing to different version of GNUcash what
> 	should be done with data base or files?
> Message-ID: <6313799.rgRFNFJjvV at legolas.kobaltwit.lan>
> 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 <adrien.monteleone at lusfiber.net>
> To: gnucash-user <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Post invoice still wants to be paid (dlbonline)
> Message-ID: <FC3D1725-5728-4158-9ADC-EBC5AA62D455 at lusfiber.net>
> 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 <geert.gnucash at kobaltwit.be> 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
>> gnucash-user at 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.
>
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 1 Aug 2018 06:42:37 -0500
> From: Adrien Monteleone <adrien.monteleone at lusfiber.net>
> To: gnucash-user <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <E5D9CEC0-6A68-482A-986B-365D6946F7AC at lusfiber.net>
> 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 <geert.gnucash at kobaltwit.be> 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 <adrien.monteleone at lusfiber.net>
> To: gnucash-user <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Post invoice still wants to be paid
> Message-ID: <5427CEDB-F5A8-4162-A70D-02A453562155 at lusfiber.net>
> Content-Type: text/plain;	charset=utf-8
>
>
>
>> On Aug 1, 2018, at 4:17 AM, Geert Janssens <geert.gnucash at kobaltwit.be> 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
> gnucash-user at 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.
>
> ------------------------------
>
> End of gnucash-user Digest, Vol 185, Issue 4
> ********************************************


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus