[GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

GnuCash - Dev mailing list
On 11/02/2019 04:03, David Carlson wrote:
> Wm,  before you run off at the mouth with all your innuendos, look at facts.

I'm hoping you get a message from Liz

If you don't there is something rotten in this list's administration.

> Did you try running a test on one of your backups from around June 2016
> using Gnucash 2.6.12 or earlier?

No.  Why? Because I own a transaction stream.  Watermelon.  My
transaction stream is the same regardless of how it is interpreted.
Golf ball.

> I think that if you do you will find that
> the Trial Balance Report is correct if you scrupulously check the settings
> to use the Average Price valuation method and check your price database to
> be sure that the transaction generated prices are present.

you may be a person of high IQ in your local community.  you don't
understand a trial balance.

>   John Ralls
> alluded to that earlier today.

JohnR isn't saying the same thing to me and you, Trump voter.

> In fact, I bet

yay, how much are you prepared to bet, you piece of shit?

My estimate is that you will bet fuck all because you are wrong.  You
are just a noisy person.

 > you could try re-running the Trial Balance Report in release
> 3.4 on a current data file using the Average Balance method of valuation.

There is no point, the valuation approach is wrong.

> There was a period when GnuCash was not entering transaction generated
> prices into the price database as Alex noted, but that was corrected some
> time ago and recent prices from recent transactions are all entered in the
> price database.

The price db has FUCK ALL to do with the TB

 >
  Granted, it will be difficult to find many of  those old
> missing transaction generated prices that involve the base currency but
> maybe they might get added back by using the trading accounts feature.  I
> have not tried that, but it might be worth a try.

You don't appear to have a clue what the issue is.

>   As Alex suggested,
> transactions that do not involve the base currency would need to be dealt
> with some other way.
>
> David Carlson


Do *not* invoke other people without their permission in future, David
Carlson

I *know* I get Liz angry but you have broken all the rules regarding
good manners by being an actual liar.  That is not easily forgiven.

--
Wm

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

Adrien Monteleone-2
In reply to this post by Alex Aycinena-2
Please tell me the intent is to *add* the book currency value, not replace the actual currency value.

I would hope that the actual currency transaction data would still be available. If you have to reconcile against statements or receipts (or suffer an audit) with foreign amounts sans their ‘book currency’ equivalents, such original data would be critical.

If so, this is how I originally conceived GC was operating till I learned otherwise.

Regards,
Adrien

> On Feb 10, 2019, at 1:46 PM, Alex Aycinena <[hidden email]> wrote:
>
>
> The 'book currency' feature is intended to deal with this by, if the 'book
> currency' feature is selected, forcing every non-book-currency split to be
> denominated in book-currency (i.e., like the trick, above, but without
> having to use a third account register) and enforcing lot tracking for each
> of these transactions (to get rid of all the off-line calculations), thus
> providing a basis for tracking cost and eliminating the need for an
> external price reference (unless you want to see an estimate of current
> value).
>


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

GnuCash - Dev mailing list
On 11/02/2019 17:30, Adrien Monteleone wrote:
> Please tell me the intent is to *add* the book currency value, not replace the actual currency value.

Our USA friends are still thinking about what a TB is for.

> I would hope that the actual currency transaction data would still be available.
 >

The actual transaction values should be prime in a TB.

> If you have to reconcile against statements or receipts (or suffer an audit) with foreign amounts sans their ‘book currency’ equivalents, such original data would be critical.
>

Agreed, you know how much the tx was for, your audit should agree.

A trial balance should never be speculative (unless you voted for Trump
in which case buying shares in jewish orientated russian biased golf
clubs that own wall building companies would seem a good idea).

Please check if your financial adviser is qualified before taking their
advice and it is with regret that I mention Judaism, Trump's son in law
is a nasty person regardless of religion.

> If so, this is how I originally conceived GC was operating till I learned otherwise.

Shrug, where do we learn more about "book currency".


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I think it is gnc not me

GnuCash - Dev mailing list
In reply to this post by Alex Aycinena-2
On 10/02/2019 19:46, Alex Aycinena wrote:
> It is possible that Wm is noting a problem in gnucash that I'm trying to
> address with my 'Book Currency' enhancement (unfortunately, a bit delayed).

I'm not antagonistic to your idea, Alex, just not sure I understand it.

> For most users who deal in a home currency most of the time and
> occasionally buy a foreign currency, say on a trip, and spend it on
> expenses, this deficiency won't show itself.

Agree, we've a person in devel yelling about just that.

> But for people who deal in
> multiple currencies often, with complicated transactions, it may.
>
> Consider the following scenario:
>
> 1. A user is based in Europe and considers their home currency to be Euros

following

> 2. The user uses Euros to buy multiple lots of GBPs at different times. The
> transactions each have different implicit exchange rates in the individual
> splits, but gnucash doesn't do any automatic lot tracking.

I think I have to intervene and say Trading Accounts is your fairy
godmother.

If you aren't using them you are a silly boy, Alex.

> Some of the GBPs
> are used for expenses expressed in EURs. The splits associated with these
> expenses also have implicit exchange rates, but they don't have any
> relationship to the purchased GBP's costs unless the user makes carefull
> off-line calculations and enters the right amounts.

I think that is a broken example.  Small transactions are allowed to be
discarded and joined into "we went out, bought a meal, had some some
drinks with lovely people in a pub", I'm not a social media person
(think it is all silly really) but don't have a problem with reality.

I think Alex is wanting to track lots when he shouldn't.

Alex: significant lots? sure; small amounts of spending? nope.  trading
accounts do this for free anyway.

> 3. The user then uses left-over GBPs to buy USDs. The split entered into
> gnucash has an implicit exchange rate of USDs to GBPs but nothing expressed
> in Euros.

You and I my be agreeing on a problem that I have noticed in the TB
regarding presumed valuations.

> If you want to run a report representing these transactions in Euros there
> is no way to do so unless you use an externally supplied exchange rate
> (e.g., from the price db) because the splits themselves don't have all the
> required information.

Yes!  I think you are a man so we will hug rather than kiss :)

All: I think I may have insulted Alex by not reading everything he said
before.  It gets confusing sometimes.

Alex: you are allowed to say I am an idiot or fool.

> If you want to run a report 'at cost', you also can't do this because item
> 3, above, doesn't contain the right information (so you have to 'fudge it'
> with an amount from the price db).

This is wrong, the cost is yours or mine, an actual cost not a price.db
cost for a remote commodity.  I agree with Alex.

> This can be overcome procedurally in
> gnucash by using the trick of entering the #3 transaction in a register of
> an account denominated in Euros even if that account isn't involved in the
> transaction.

Why would you do that?  I am asking because I can't see the point.

> One split will sell the GBPs in EURs, the other will buy USDs
> in EURs and as soon as you hit the enter key, the transaction will
> 'disappear' from the register it was entered in (since neither of the
> splits were for that account).

I wrote some stuff below and now I am asking, how do you get gnc to
disappear splits?  I am in favour of gnc keeping them.

> The transaction, however, will show up in
> the registers for the accounts involved and they will contain the implicit
> exchange rates that were missing above (but not necessarily with any lot
> tracking and still requiring a lot of off-line calculations to figure out
> the right numbers to enter into the splits).

Alex: you said something important there.  I'm sure I'm not fighting
with you.

Thinking: there is something significant in Alex's para above, I think I
need to read it again.  I may not reach the same conclusion but it would
be stupid if I didn't understand.

> Now a report 'at cost' could
> be run, but only if the trick was used procedurally for every transaction
> not involving the home currency. Of course, this can't be assumed to be the
> case.

I'm not convinced, if the report shows holdings in each commodity and
currency and it works every time <-- it has to, there are some times
pretending to be clever doesn't work, I think we are getting to that
point with Alex's proposal.

> The 'book currency' feature is intended to deal with this by, if the 'book
> currency' feature is selected, forcing every non-book-currency split to be
> denominated in book-currency

No!  No!  No!  Don't be aggressive towards good accounting!

> (i.e., like the trick, above, but without
> having to use a third account register)

you don't need to

> and enforcing lot tracking for each
> of these transactions (to get rid of all the off-line calculations),

also superfluous (there are reasons to use lot tracking) but lot
tracking *and* trading accounts leaves me thinking, hang on, maybe one
person doesn't understand the other person?

> thus
> providing a basis for tracking cost and eliminating the need for an
> external price reference (unless you want to see an estimate of current
> value).

Why wouldn't someone want to know the current value of stuff?

Are you so involved with the tiny penis Trump thinking that your USD is
worth a different amount to the USD I have?

> I don't know if this is related to the problem Wm is seeing, but it might
> be.

It looks like something no adult should implement unless explained better.

--
Wm


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12