[GNC] gnucash-user Digest, Vol 184, Issue 1

Stan Brown the_stan_brown at fastmail.fm
Sun Jul 1 17:54:04 EDT 2018


> On 29/06/2018 I backed up my GNU file.
> I did some editing, entering additional transactions and 
> reconciliations on the 30th, and today, without realizing that
> GNUcash had opened up my backup file instead.
I've been there, and I feel your pain.  You've already seen people's
suggestions for the immediate situation, but here's how I stop myself
from making that mistake again.

I've hidden my shortcut to the GnuCash _program_, and instead have a
shortcut to my GnuCash _data file_. Windows recognizes the .gnucash file
type, and launches GnuCash with that data file. Internally I imagine
it's a command-line argument, so something similar should work in other
OSes, or at least you could make a shortcut or alias to "GnuCash {your
data file name}".

-- 
Regards,
Stan Brown
Tompkins County, New York, USA
http://BrownMath.com
http://OakRoadSystems.com


On 2018-07-01 04:01, 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:  Windows strawberry perl and online prices (David Carlson)
>    2. Re:  Rethinking the placeholder account concept (was: Re:
>       Fwd: The two modules) (Christian Kluge)
>    3. Re:  How To Record an In-Kind Charitable Donation?
>       (Mike or Penny Novack)
>    4. Re:  How To Record an In-Kind Charitable Donation? (Rich Shepard)
>    5. Re:  GnuCash 3.2 Released (DaveC49)
>    6. Re:  Rethinking the placeholder account concept (was: Re:
>       Fwd: The two modules) (DaveC49)
>    7. Re:  Change Reconcile Starting Balance (D)
>    8. Re:  How to regularly use two currencies (Norbert Klein)
>    9.  My bad (Tony Vanson)
>   10. Re:  My bad (Colin Law)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 30 Jun 2018 16:17:00 -0500
> From: David Carlson <david.carlson.417 at gmail.com>
> To: Tim Kallmer <tkallmer at gmail.com>
> Cc: Gnucash Users <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Windows strawberry perl and online prices
> Message-ID:
> 	<CADYgSbkMCArX_+yUaBZ7VQX_Qw5SHRer89jZqtpBskh0TMyehQ at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> Actually, I have a very similar problem which I have not had time to track
> down yet.  I think that it is somewhere in the Finance:Quote configuration,
> but I am not sure.
> 
> David C
> 
> On Sat, Jun 30, 2018 at 3:24 PM, Tim Kallmer <tkallmer at gmail.com> wrote:
> 
>> ?I actually did uninstall strawberry perl and the leftover strawberry
>> folder when I went to 3.2, and when I went back to 2.6. It didn't make a
>> difference.?
>>
>>
>> On Sat, Jun 30, 2018 at 12:00 PM, David Carlson <
>> david.carlson.417 at gmail.com> wrote:
>>
>>> There has been some discussion in this list recently suggesting that
>>> especially when changing between releases from the 2..6 series and 3.0, 3.1
>>> or 3.2, one should uninstall the previous version manually.  In Windows,
>>> the Control Panel uninstall feature should work.  If you did not do that
>>> you may need to manually delete some files before installing a new
>>> version.  I am not sure where to look for detailed instructions.
>>>
>>> I think 3.2 or 2.6.21 are the preferred releases, depending on which
>>> works better for you.
>>>
>>> David C
>>>
>>> On Sat, Jun 30, 2018 at 10:40 AM, Tim Kallmer <tkallmer at gmail.com> wrote:
>>>
>>>> Has anyone using gnucash on windows had online prices stop working? For
>>>> me
>>>> the strawberry perl window opens and never finishes after hours of
>>>> waiting.
>>>> I eventually have to close the window and give up. I've tried
>>>> un/reinstalling gnucash and perl. I've tried 3.1 and 3.2 and 2.6. I've
>>>> double-checked my alphavantage key is correct. Any suggestions?
>>>> _______________________________________________
>>>> 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: 2
> Date: Sat, 30 Jun 2018 23:23:49 +0200
> From: Christian Kluge <frakturfreak at gmail.com>
> To: gnucash-user at lists.gnucash.org
> Subject: Re: [GNC] Rethinking the placeholder account concept (was:
> 	Re: Fwd: The two modules)
> Message-ID: <ph8s91$45m$1 at blaine.gmane.org>
> Content-Type: text/plain; charset=utf-8
> 
> Am 30.06.2018 um 22:52 schrieb John Ralls:
>>
>>
>>> On Jun 30, 2018, at 12:00 PM, Christian Kluge <frakturfreak at gmail.com> wrote:
>>>
>>> Am 30.06.2018 um 05:37 schrieb John Ralls:
>>>>
>>>>
>>>>> On Jun 29, 2018, at 3:26 PM, Christian Kluge <frakturfreak at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am 29.06.2018 um 19:26 schrieb John Ralls:
>>>>>>
>>>>>>
>>>>>>> On Jun 29, 2018, at 9:52 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>>>>>>>
>>>>>>> Op vrijdag 29 juni 2018 16:59:07 CEST schreef John Ralls:
>>>>>>>> Stock accounts need to have a parent denominated the currency in which the
>>>>>>>> stock trades in order for the asset roll-up to work correctly on the
>>>>>>>> Accounts page. Three-commodity transactions are possible using trading
>>>>>>>> accounts, but I haven?t dealt with that stuff in a while and the details
>>>>>>>> have gone fuzzy on me.
>>>>>>>>
>>>>>>>> Stock accounts aside, let?s not conflate different purposes. We *should*
>>>>>>>> have an account type to accommodate the European Passive account with
>>>>>>>> Liability and Equity children, so let?s create that. We?ll need to tweak
>>>>>>>> some of the reports a bit to accommodate it, but otherwise it won?t have
>>>>>>>> much impact. It should, of course, be what we now call a placeholder and it
>>>>>>>> should be able to have only Root as a parent and only one each Liability
>>>>>>>> and Equity placeholder children.
>>>>>>>>
>>>>>>> I was in fact deliberately trying to come up with a solution that's more 
>>>>>>> flexible than fitting the currently known use cases. The European Passive 
>>>>>>> account was just one example.
>>>>>>>
>>>>>>> However we may be spending more time on it than necessary. I checked in the 
>>>>>>> current version of the commercial accounting package* I also have to deal with 
>>>>>>> and it doesn't define a Passive type at all. "Passive" it doesn't even appear 
>>>>>>> on its default balance sheet. That is a bit uncommon though as the reports I 
>>>>>>> get from my accountant do have a passive section. However just like gnucash 
>>>>>>> this package is targeting a worldwide audience (though with country specific 
>>>>>>> extensions). That may explain why they didn't bother adding the Passive 
>>>>>>> section.
>>>>>>>
>>>>>>> Let me add that contrary to other accounting packages I have played with in 
>>>>>>> gnucash the chart of accounts takes a very central place. So whether or not we 
>>>>>>> want our own Passive type to group liabilities and equity hierarchically on 
>>>>>>> the chart of accounts as well is up for debate.
>>>>>>>
>>>>>>>> I don?t think that creating a generic placeholder type account that can have
>>>>>>>> children of any type is a good idea,
>>>>>>>
>>>>>>> Here's another example: a household that wants to  track its finances, but 
>>>>>>> would want to keep separate account hierarchies per family member. Standard 
>>>>>>> response: create two files. However they would benefit from common reporting 
>>>>>>> which is cumbersome with two separate files. So what if we would allow to 
>>>>>>> create two independent account hierarchies in one file. With a view type 
>>>>>>> account one could create two top-levels ("Husband" and "Wife") and create a 
>>>>>>> independent hierarchy for each. While this could also be solved if we would 
>>>>>>> allow multiple root accounts and make that root visible I'm using it here to 
>>>>>>> illustrate there are use cases we are not covering well.
>>>>>>>
>>>>>>> I borrowed the idea of a view type account from an old version of the 
>>>>>>> commercial package* we have to use. Looking more closely it turns out the 
>>>>>>> current version has dropped view accounts and instead is organizing charts/
>>>>>>> reports using a combination of account type (roughly like we do) and 
>>>>>>> hierarchical account numbers. So I must admit perhaps the idea was not so 
>>>>>>> bright after all :)
>>>>>>>
>>>>>>> The package also doesn't have a hierarchical account tree. It's flat and 
>>>>>>> hierarchy is only added in reports as explained above. So there is no such 
>>>>>>> thing as a parent account in that package and hence no restriction on which 
>>>>>>> account type a certain account can be.
>>>>>>>
>>>>>>> Again in gnucash the chart of accounts is very central and visible so we 
>>>>>>> probably shouldn't drop its hierarchical structure just yet.
>>>>>>>
>>>>>>> The downside of this hierarchical structure is then of course we have to think 
>>>>>>> about issues like  whether or not we should allow accounts to have any type of 
>>>>>>> child or not. I believe parts of gnucash rely on this (I seem to remember a 
>>>>>>> relatively recent issue in the export code that it didn't find all liability 
>>>>>>> accounts if they had a non-liability parent or such).
>>>>>>>
>>>>>>>> and I think that we already have too
>>>>>>>> many overlapping account types with subtle behavior differences that are
>>>>>>>> neither documented nor easily discoverable in code.
>>>>>>>>
>>>>>>> I'm all for clearing this up. If we can reduce the number of account types 
>>>>>>> that would be great. 
>>>>>>> For reference this is the list of 17 account types supported by the commercial 
>>>>>>> package*:
>>>>>>> Receivable, payable, bank and cash (one type), current assets, non-current 
>>>>>>> assets, prepayments, fixed assets, current liabilities, non-current-
>>>>>>> liabilities, equity, current year earnings, other income, income, 
>>>>>>> depreciation, expenses, cost of revenue, credit card.
>>>>>>>
>>>>>>> Gnucash currently has 15 of which a few are internal only:
>>>>>>> Bank, cash, credit, asset, liability, stock, mutual, currency, income, 
>>>>>>> expense, equity, receivable, payable, root and trading.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The leftovers from this long discussion for immediate use may be summarized 
>>>>>>> as:
>>>>>>> - on reports display placeholder accounts once as aggregate account and once 
>>>>>>> as its own account if it has splits.
>>>>>>> - work to be more pedantic about the meaning of "placeholder". It should 
>>>>>>> become an empty account used for structuring the account hierarchy and for 
>>>>>>> collecting (sub)totals.
>>>>>>> - introduce a read-only status for accounts one doesn't want to accidentally 
>>>>>>> modify, but that should still appear in the chart of accounts in various 
>>>>>>> places
>>>>>>> - replace "hidden" combined with current "placeholder" with "inactive".
>>>>>>> - consider introducing a passive account type to be able to structure the 
>>>>>>> chart of accounts and reports conform European habits.
>>>>>>> - think of ways to have more than one chart of account in one file (only 
>>>>>>> mentioned first in this message).
>>>>>>
>>>>>> There?s been an effort over the last several years between the IASB and the US?s FASB to reconcile IAS and US GAAP for the obvious reason that it?s a royal PITA for international businesses to have to present their books in different ways to different regulators. I discovered when looking for an IAS example CoA earlier today that it?s apparently come to fruition as IFRS and that the standard CoA doesn?t have a ?Passive? super-category [1], so perhaps the rest of the world is catching up with GnuCash. ;-)
>>>>>>
>>>>>
>>>>> Not the whole world. Section 266 of the German HGB requires the balance
>>>>> sheet to split in active and passive and that?s how it?s displayed in
>>>>> every German accounting software.
>>>>>
>>>>> https://www.gesetze-im-internet.de/hgb/__266.html <https://www.gesetze-im-internet.de/hgb/__266.html>
>>>>>
>>>>> Also while you add it think about new account structures and the
>>>>> placeholder concept could you also consider the equivalents of the other
>>>>> types mentioned in the document above.
>>>>
>>>>
>>>> No surprise that individual country?s legislation hasn?t caught up. That will likely take several more years.
>>>
>>> I hope this will never happen because the American way of doing it
>>> destroys the fundamental aesthetic of the balance sheet, that there two
>>> numerically identical sides which have just one top label each.
>>>
>>>> I don?t see any account types there other than the Active/Passive sections that GnuCash doesn?t already support. What I can?t figure out is what parts of the CoA small companies are allowed to leave out. (And no, my German isn?t good enough to thoroughly read the document. I used Google translate and so I may have gotten some of it wrong.)
>>>
>>> To summarize which sections each company type has to use:
>>>
>>> micro-entities: capital letters
>>> small sized: capital letters + Roman numerals
>>> medium sized and large: capital letters + Roman numerals + numbers
>>
>> Thanks.
>> So it's just that larger companies have to report more detail?
>>
> 
> There are some exceptions, like limited partnerships with a limited
> liability company as general partner (GmbH & Co. KG) being required to
> list a more detailed break-down of their equity regardless of their size
> and stock market oriented companies always being treated as large
> companies but basically yes, the larger the company the more detailed
> the reports have to be.
> 
> Regards
> 
> Christian Kluge
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Sat, 30 Jun 2018 18:57:09 -0400
> From: Mike or Penny Novack <stepbystepfarm at dialup4less.com>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] How To Record an In-Kind Charitable Donation?
> Message-ID: <5B380AC5.80300 at dialup4less.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 6/30/2018 3:10 PM, Eric H. Bowen via gnucash-user wrote:
>> I performed some design work and provided custom-printed envelopes and
>> materials for a local 501c3 charitable ministry. I am not charging them
>> money for the items, but I would like to receive credit for their fair
>> market value as an in-kind charitable donation. The ministry's treasurer
>> said to send him an invoice for the material and he would acknowledge
>> its receipt as a donation. Am I able to use Gnucash to track this
>> donation and, if so, what is the proper way to record the activity?
> The proper way is the way your tax lawyer/accountant tells you to. Once 
> THAT has been settled, we can then tell you "how in gnucash".
> 
> I lack the "qualifications" to give this sort of advice, especially as 
> there are two parts to it. The "materials" part of it is easy, a debit 
> to donations and a credit to your materials inventory. The "design work" 
> part of it I would not be willing to hazard a guess. Maybe somebody on 
> this list who donates professional services might answer.
> 
> Michael D Novack
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 30 Jun 2018 16:10:07 -0700 (PDT)
> From: Rich Shepard <rshepard at appl-ecosys.com>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] How To Record an In-Kind Charitable Donation?
> Message-ID:
> 	<alpine.LNX.2.20.1806301606530.12189 at salmo.appl-ecosys.com>
> Content-Type: text/plain; format=flowed; charset=US-ASCII
> 
> On Sat, 30 Jun 2018, Mike or Penny Novack wrote:
> 
>> The proper way is the way your tax lawyer/accountant tells you to. Once THAT 
>> has been settled, we can then tell you "how in gnucash".
> 
>    FWIW, I make non-cash donations to Goodwill several times each year. What
> I did (and my accountant confirmed is appropriate, at least for Oregon and
> the feds) is set up two accounts: an asset account, 'Goodwill,' and an
> expense account, 'Donations (non-cash).' If I donate time and effort to a
> non-profit other than Goodwill I'll add another asset account and use that
> to offset the non-cash donation.
> 
> Regards,
> 
> Rich
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sat, 30 Jun 2018 01:26:57 -0700 (MST)
> From: DaveC49 <davidcousens at bigpond.com>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] GnuCash 3.2 Released
> Message-ID: <1530347217312-0.post at n4.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi John,
> 
> If GnuCash is not built with Ninja, there is a cmake_uninstall.cmake file in
> the top level of the build directory which seems to read the
> install_manifest.txt file. The Makefile in the same level produced by CMake
> has an uninstall target - not sure how it executes the commands in the
> cmake_uninstall.cmake file but it appears to. 
> 
> Executing "make uninstall" ( prefixed with sudo if installed in a system
> location) in the build directory does remove all of the GnuCash files
> installed in the <prefix> specified to cmake. (GnuCash V3.2 from the
> SourceForge tarball on Linux Mint 18.3 built using Cmake, make and - should
> be the same for Ubuntu).
> 
> Not sure that happens if it is built with Ninja rather than make though.
> 
> David Cousens
> 
> 
> 
> -----
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Sat, 30 Jun 2018 16:57:12 -0700 (MST)
> From: DaveC49 <davidcousens at bigpond.com>
> To: gnucash-user at gnucash.org
> Subject: Re: [GNC] Rethinking the placeholder account concept (was:
> 	Re: Fwd: The two modules)
> Message-ID: <1530403032780-0.post at n4.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Stephen John, Geert
> 
> In accounting terms there are really only 3 basic account types:
>   Asset
>   Liability
>   Equity
> 
> These all *must *satisfy the basic accounting equation Assets=Liabilities
> +Equity.   
> 
> The two sides of this equation are what the German /European system defines
> as Activa and Passiva but these groupings are primarily reporting
> requirements not account heirarchy. Is there really a need to have an
> additional placeholder category as the reporting grouping can be readily
> defined from the existing basic account heirarchy structure?
> 
> Each type can have function specific sub-types which impose functional
> restrictions for that subtype and where the children but these subtypes are
> always one of the above basic types. Children of the types and sub-types
> must conform to the restriction that they have the same type or subtype as
> the parent E.g.
> 
> Asset                                                                        
> Top level placeholder
>    Current                                                                  
> placeholder
>          Bank
>          Accounts-Receivable                                         
> business - no children
>          Stock
>          Trading
>    Non-current                                                           
> placeholder
> 
> Liability                                                                     
> Top level placeholder
>     Accounts payable                                                   
> business functionality-no children
> Equity                                                                       
> Top  level placeholder
>     Income                                                                 
> Current period revenue placeholder
>     Expenses                                                              
> Current period expenditure placholder
> 
> My experimentation and what I have understood of the code is this is already
> what GnuCash imposes in its account heirarchy with the exception perhaps
> that Income and Expenses are treated as their own types and the Equity type
> is enforced in any end of period closing operations and/or in the reporting
> and the expanded version of the accounting equation is enforced in the code.
> 
> Assets=Liabilities + Equity + Income - Expenses
> 
> For business purposes it is usually a requirement that each legal entity
> should have it's own set of books.   I handle the situation where I need to
> separate different individual contributions within an entity in the manner
> John suggested (e.g. a household or a partnership) with labelled subaccounts
> within each type as defined above. If there really is a need to fully
> separate the individuals in terms of separately recording assets,
> liabilities and equity, then it is appropriate to run a separate set of
> books.
> 
> I think it would be useful/nice to clearly document somewhere, perhaps the
> wiki, what the existing account structure is at this point and what
> attributes accounts currently have and what their intended purpose is from
> the developers point of view as well as the other unintended uses that the
> user base can come up with. That could then provide a basis for looking at
> restructuring those attributes. Something like the design documents that
> were produced at times in the past. This would also give the documenters a
> chance to reflect that in the documentation.
> 
> David Cousens
> 
> 
> 
> 
> 
> -----
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sun, 01 Jul 2018 00:33:48 -0400
> From: D <sunfish62 at yahoo.com>
> To: Roger Miskowicz <rmisko11 at gmail.com>
> Cc: Gnucash Users <gnucash-user at gnucash.org>
> Subject: Re: [GNC] Change Reconcile Starting Balance
> Message-ID: <yrvya9bwcoalktrx2qi3tm2k.1530419540288 at email.android.com>
> Content-Type: text/plain; charset=utf-8
> 
> I'm glad you've fixed it.
> 
> On June 30, 2018, at 3:04 PM, Roger Miskowicz <rmisko11 at gmail.com> wrote:
> 
> I have fixed my account but not sure about the root cause.
> 
> 
> I fixed it by manually, item-by-item, clearing all reconciles which set the? Starting Balance? to zero.? After which I was able to reconcile producing results I expected.
> 
> 
> Thanks for helping me fix it.
> 
> 
> Roger
> 
> 
> P.S.? A nice feature would be the abililty to select a bunch of items to set or clear reconciles.
> 
> 
> 
> On Sat, Jun 30, 2018 at 8:55 AM, D <sunfish62 at yahoo.com> wrote:
> 
> Only manually, a transaction at a time.
> 
> What happens if you ignore the opening balance, enter the correct closing balance, and reconcile then?
> 
> Often, if there's an inconsistency in the opening balance, you can proceed with reconciling, mark your current transactions and any earlier ones that were missed before (such as your opening balance transaction, say), and they balance out.
> 
> David
> 
> 
> On June 30, 2018, at 8:23 AM, Roger Miskowicz <rmisko11 at gmail.com> wrote:
> 
> Thanks Colin.
> 
> Is there anyway I can clear all reconcilation of the the account and start
> again from scratch?
> 
> Roger
> 
> On Sat, Jun 30, 2018 at 8:15 AM, Colin Law <clanlaw at gmail.com> wrote:
> 
>> The starting balance in the reconcile start dialog will be the nett
>> balance of all reconciled transactions so far. Is this the first time
>> you have reconciled it?? If not then it should be the same as the
>> ending balance the last time you reconciled, unless you have editted a
>> reconciled transaction.
>>
>> Colin
>>
>> On 30 June 2018 at 13:08, Roger Miskowicz <rmisko11 at gmail.com> wrote:
>>> I am using GC Version 3.2 and trying to reconcile my Credit Card Account
>>> which I started at the beginning of the year with an opening balance.
>>>
>>> I would like to reconcile the account from the opening balance but I
>> don't
>>> know how to set the 'starting balance' which happens to be some number
>> that
>>> doesn't seem relevant.
>>>
>>> Can the 'starting balance' in 'reconcile' be manuallly set, and if so,
>> how?
>>> _______________________________________________
>>> 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.
>>
> _______________________________________________
> 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: 8
> Date: Sun, 1 Jul 2018 12:02:32 +0700
> From: Norbert Klein <nhklein at gmx.net>
> To: Geert Janssens <geert.gnucash at kobaltwit.be>
> Cc: gnucash-user at gnucash.org
> Subject: Re: [GNC] How to regularly use two currencies
> Message-ID: <702e48af-e3ae-bff1-35bd-ff4c77148414 at gmx.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Thanks, Geert,
> 
> for you clear and specific suggestions.
> 
> I think they will result in what I need - I will try to implement it and 
> will let you (and gnucash-user at gnucash.org) know after some days.
> 
> There will be - as far as I can see now - only one additional procedure 
> necessary (and a short additional time) for every shop action: to do the 
> transaction from Riel to US$. But that is OK if all the other results 
> will be what we need.
> 
> Thanks again for thinking through our special Cambodian "regularly two 
> currencies" situation.
> 
> Norbert
> 
> =
> 
> 
> On 30.6.2018 17:56, Geert Janssens wrote:
>> Hi Norbert,
>>
>> While you seem to think you want to account in multiple currencies, your
>> replies so far all suggest you only want to track payments in multiple
>> currencies.
>>
>> I read these requirements:
>> Quote 1:
>> "I have to know - at the end of the  day - how many US$, and how many Riel,
>> should be in the cash boxes."
>> Quote 2:
>> "But while I have to keep track of the actual cash in the cash boxes, at
>> certain times (daily, weekly, monthly etc.) I also need to know "how we did as
>> a business" and this should say something in US$ (for all the activities which
>> did happen in both currencies)."
>>
>> So essentially this says you want to keep track of two cash boxes: one in US$
>> and one in Riel. Yet in the end you estimate your business in US$.
>>
>> So your income and expense accounts should only exist in US$, while in your
>> assets you will can two cash accounts: one in US$ and one in Riel.
>>
>> When a customer pays you in Riel, you make a transaction from your Riel cash
>> box account to your single income account (which is in US$) and apply the
>> exchange rate from Riel to US$ to that transaction. By default gnucash will
>> ask you for this exchange rate. If a customer pays in US$ you create a
>> transaction from your US$ cash box account to your income account. As the
>> currencies match there's no conversion rate to apply.
>>
>> The same goes if you pay for expenses or goods to a supplier. If you pay in
>> Riel you create a transaction from the Riel cash box account to the
>> appropriate expense account (which is always in US$). If you pay in US$ the
>> money goes out of your US$ cash box account into the (same) US$ expense
>> account.
>>
>> That will give you all the information you request:
>> Do you want to know what's in your cash boxes ? Check the appropriate cash box
>> account or generate a report over it.
>> Do you want to know how you did as a business ? Generate a report over your
>> income/expense accounts which are in US$.
>>
>> Unless you have other requirements you didn't mention I don't think you need
>> the parent/multi-currency-subaccount structure in your income and expense
>> accounts as you have currently set up. And it will probably simplify your
>> accounting if you could do without.
>>
>> Regards,
>>
>> Geert
>>
>> Op zaterdag 30 juni 2018 11:58:51 CEST schreef Norbert Klein:
>>> Thanks, Geert,
>>>
>>> I will respond between the lines.
>>>
>>> On 29.6.2018 17:58, Geert Janssens wrote:
>>>> Hi Norbert,
>>>>
>>>> I don't know the accounting customs of your country,
>>> There are no general accounting customs set - everybody does what seems
>>> to cover the needs of he place.
>>>
>>>> so first a question:
>>>> Is it common in Cambodia to *account* in two currencies as well or only to
>>>> *pay* in two currencies ?
>>> In daily life, we may *pay* in either of the two currencies - it is only
>>> customary to make payments in Riel for small and in US$ for larger
>>> amounts. But again, there is no general definition what is "larger" - it
>>> is easier to handle bigger "values" in US$, where 1 US$ corresponds to
>>> roughly 4000 Riels.
>>>
>>> We may ask in our shop - as an example - for a price of US$ 4.00, but
>>> the person may hand over 16,000 Riel. Or the other way round. I do not
>>> know if there are many countries with such a situation. But here it is
>>> totally flexible - every person, for every purchase, may choose one way,
>>> and the next minute for another purchase the other way.
>>>
>>> So the answer is: BOTH - we pay in two currencies, but we also have to
>>> account in two currencies.
>>>
>>> So in the shop we have a Riel cash box, and a US$ cash box, and while we
>>> enter for each purchase an amount - and I have to enter the amount
>>> either into the "Cash in wallet $" or into the "Cash in wallet Riel" -
>>> because we have all the time changes in both cash boxes. And for the
>>> same purchase I enter the amount either into the sub-account "Vegetables
>>> $" or "Vegetables R" - both under ONE Placeholder account "Vegetables"
>>> (set for US$)
>>>
>>>> Or put differently - do you want to track your income in the two
>>>> currencies or just in one (hence the placeholder account) ?
>>> For the actual conducting of purchases, I am tracking the US$ purchases
>>> and the Riel purchases separately - but I put both under ONE placeholder
>>> because I am not only interested in individual purchases, but also in
>>> the overall income (or loss) situation. I had assumed to have a common
>>> placeholder would serve this purpose. Maybe this was wrong.
>>>
>>>> But you do want to be able to
>>>> accept/make payments in the two currencies ?
>>> Yes - it depends on the buyer - depending of which of the two currencies
>>> he of she has in their purse.
>>>
>>>> If you only want to accept/make payments in two currencies but just track
>>>> it in one, the account structure would be slightly different.
>>> "track it only in one" - for the actual operation of the shop this is
>>> not possible. I have to know - at the end of the  day - how many US$,
>>> and how many Riel, should be in the cash boxes.
>>>
>>>> If you want to track your income in multiple currencies as you have set
>>>> up,
>>>> you'll need to make sure you have entries in your price database for
>>>> conversion rates between USD and Cambodia Riel.
>>> In my former mail, I had said: "(In Tools, Price Editor, I have set
>>> Khmer Riels as the second currency in addition to US$.)" - saying that 1
>>> US$ corresponds to 4000 Riel, with hardly any fluctuation. Any more to do?
>>>
>>> But while I have to keep track of the actual cash in the cash boxes, at
>>> certain times (daily, weekly, monthly etc.) I also need to know "how we
>>> did as a business" and this should say something in US$ (for all the
>>> activities which did happen in both currencies).
>>>
>>>> Or more generally between your
>>>> book's currency and the foreign currencies you trade in.
>>> Well, I do not feel that "we trade in a foreign currency" - both
>>> currencies co-exist here in everybody's wallet. Te bill from the
>>> electricity company comes in Riel, the bill from the ISP comes in US$ - etc.
>>>
>>> So what else can you please suggest to me to do?
>>>
>>> Really many thanks,
>>>
>>> Norbert
>>>
>>>> Regards,
>>>>
>>>> Geert
>>>>
>>>> Op vrijdag 29 juni 2018 12:28:00 CEST schreef Norbert Klein:
>>>>> How to regularly use two currencies
>>>>>
>>>>> I would very much appreciate if somebody could help me to solve a
>>>>> problem.
>>>>>
>>>>> In GnuCash 2.6.19,on a Windows 10 computer, I made the following
>>>>> arrangements ? but maybe my assumptions were wrong, as I cannot see the
>>>>> results I had hope for. I do not have much experience, so I dare to ask
>>>>> for advice and help.
>>>>>
>>>>> I live in Cambodia, where it is usual all over the country to use two
>>>>> currencies regularly: the Cambodian Riel, and the US$ (at normally 4000
>>>>> Riel per Dollar).
>>>>>
>>>>> (In Tools, Price Editor, I have set Khmer Riels as the second currency
>>>>> in addition to US$.)
>>>>>
>>>>> I live on a farm, where, among other things, we produce, sell, and buy
>>>>> vegetables.
>>>>>
>>>>> Under Income, I created an account FARM, and under FARM an account SHOP,
>>>>> and under shop a Placeholder account VEGETABLES (currency USD). Under
>>>>> VEGETABLES I created a VEG$ sub-account for business in US dollars, and
>>>>> another sub-account VEGR for business in Riels.
>>>>>
>>>>> Now I enter all business actions into VEG$ or VEGR, either as Income or
>>>>> Charge, according to the currency used.
>>>>>
>>>>> After some entries, I can see the calculated result (gain or loss) in
>>>>> US$ in the Placeholder account VEGETABLES.
>>>>>
>>>>> I had hoped that the entries in VEGR would be transferred into US$ and
>>>>> also be part of the reported results in the placeholder account
>>>>> VEGETABLES ? but this is not the case.
>>>>>
>>>>> Now my kind request:
>>>>>
>>>>> 1) please tell me if there is a way to get also the Riel values
>>>>> reflected in the Placeholder account above the VEGR; I had assumed that
>>>>> this should be possible with Placeholder accounts which are ?intended to
>>>>> be used for hierarchical organization of accounts? - but maybe not when
>>>>> different currencies are involved?
>>>>>
>>>>> 2) please give me advice if all this is wrong ? how could I handle our
>>>>> situation? Every purchase and sale has to be recorded in one of the two
>>>>> currencies.
>>>>>
>>>>> My hope was to get the overall results in US dollars in this way ? and
>>>>> the goal remains the same: at the end of he day/week/month, I want to
>>>>> know how we did manage ? all calculated in US$.
>>>>>
>>>>> Thanks for any help.
>>>>>
>>>>> Norbert KLEIN
>>>>>
>>>>> _______________________________________________
>>>>> 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: 9
> Date: Sun, 1 Jul 2018 14:47:59 +0700
> From: Tony Vanson <tonyvans70 at gmail.com>
> To: gnucash-user <gnucash-user at gnucash.org>
> Subject: [GNC] My bad
> Message-ID:
> 	<CACnjAud7-OXyfk12Q_QgnMR2Xz_GmtV-=brC1vENKhTveMcXXA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi all,

> 
> 


More information about the gnucash-user mailing list