[GNC] Trial balance

2023-01-07 Thread Fred Tydeman
I have run a Transaction report (for all accounts) for just one day in the
past (to find all the transactions on that one day).  It found just one
transaction where I bought 600 yuan for 99.07 USD (at an ATM in china).
The grand totals in the report are 0 USD and 0 yuan.

That one transaction has four splits:
Receive column:
  Assets:...:$china 600
  Trading:cash US:ftexx 99.07 Fid. TE MM
Spend column:
  Assets:..:Fid. TE MM  99.07 Fed. TE MM
  Trading:CURRENCY:CNY  600

That transaction is the first one in $china.  There is no Equity Opening
Balance (which would be zero) for $china.

I then ran a Trial Balance report; again for just that one day and all
accounts.  The two totals at the bottom of the report do not match (differ
by 5.46).  If I change the date to 6 days earlier (again for just one day),
the two totals match.

By one day, I mean both Start date and Date of report are the same.

OS:  Fedora Linux 37
GnuCash: 4.13
Trading accounts are on.

Is Trial Balance supposed to work when there is a mixture of currencies?
Is Trial Balance supposed to work for just one day in the past?
Do all accounts need an Equity Opening Balance?
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Dr. David Kirkby
On Sat, 7 Jan 2023 at 23:15, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Yes, the principle of Materiality.


The link Geoff gave was quite useful to me. I have noticed some differences
between my calculations and my accountants before. He has replied “That
will be reflected in next year’s accounts”. It was only £5.59, but I knew
could not be explained by rounding errors.

Now this maybe a misunderstanding on my part, and may depend upon the
jurisdiction, but here’s one example. For my last years accounts (ending
February 28th 2022), the money in the bank account at the end of the
financial year was X. He submitted X to Companies House. Yet there were two
transactions shown on the bank statement on 1st March, but shown with a
date in late February. I thought he was supposed to include those two
transactions in last years accounts, but he didn’t. He has not answered my
email on the topic. He probably determines that they are immaterial, as
they total about £15.

>
> It isn't worth spending time looking for small errors. Just adjust them
> out and move on.


That would niggle me. In any case, I would not know how to adjust it
properly.

My background is science, (I have a Ph.D not a medical degree). A number of
scientific discoveries have been made by people who refuse to ignore things
that could easily have been dismissed as insignificant. I suppose that I
need to get out of that habit when chasing immaterial amounts of money.

>
> Otherwise, I'd say enter the transaction on what you think is the proper
> date and re-reconcile.


That’s what I have now done. I stuck the earlier date. I don’t have any
record of the cancellation - I didn’t record it and Royal Mail didn’t email
me any confirmation of the cancellation. But I know that £0.60 was the fee
to get a parcel collected, so I knew what it would be.


> But that begs the question, how did you reconcile without it?


The truth is that in this point in time, I am trusting the bank’s records
more than my own when it comes to small things like that, as I would not
have bothered recording that I sought a £0.60 refund. The only reason I
would bother going to the Royal Mail website and cancelling the pickup
would be to save the postman a wasted journey. I would not have bothered
recording it in my spreadsheet. But now I am using GnuCash, I will record
these sorts of things.

>
> If you had to make an adjusting entry, that will also need to be edited
> or deleted.


I will have to find out how to handle adjustments. It is an area of
accounting that I don’t understand, but are willing to learn.

Regards,
>
Adrien


Dave.

> --
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkir...@kirkbymicrowave.co.uk
https://www.kirkbymicrowave.co.uk/
Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread David H
If, as Adrien's post asks, it is a credit card type account you are
reconciling check Preferences >> Register >> Automatic credit card payment
- if it's set on you'll get the popup.

Cheers David H.

On Sun, 8 Jan 2023 at 10:09, Kevin T via gnucash-user <
gnucash-user@gnucash.org> wrote:

> OK.   getting that off the plate.
> When i do a reconcile, change the date to the previous reconcile datae,
> and the balances match, with no manipulations, when I click the finish
> button, a funds transfer form pops up!
> I saved, exitted, restarted and this behavior is consistent.
> Is that considered normal?
> Kevin
>
> On Saturday, January 7, 2023 at 02:54:44 PM CST, David T. <
> sunfis...@yahoo.com> wrote:
>
>  Your records and the bank's differ. The reconciliation date may include
> entries that you've entered with later dates, and how would GnuCash
> determine the proper cutoff?
>
> Personally, I don't have trouble determining when the difference figure
> goes to 0.
>
> David T. On Jan 7, 2023, at 11:45 PM, Kevin T via gnucash-user <
> gnucash-user@gnucash.org> wrote:
> Is there some reason that the reconcile feature looks past the closing
> date specified?
> I have imported numerous months of transactions for an account.  Trying to
> reconcile only the first month with 0 balance and 0 transactions before the
> starting date.  I provide the 'statement date' to the reconcile feature and
> it brings up every transaction entered, even the ones after the 'statement
> date'.
> This is not how a person would reconcile this.  We could concern ourselves
> with on the transactions that occur before the closing date 'statement
> date'.
> Is there something I am missing ?
> Kevin
>
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] NEw user assistance

2023-01-07 Thread Jim DeLaHunt

Karl:

I understand your situation. I also keep my books primarily in Canadian 
dollars, but track investments in US dollars.


On 2023-01-07 09:56, Karl wrote:

…If I purchase foreign stocks
(foreign to Canada), my broker automatically converts my CAD "broker cash
account" to USD to purchase the stock. There is no need for me to have two
broker cash accounts (one for CAD and one for USD) - all my investment cash
is kept in one account, in CAD.…


So you are saying that your broker does not show you as having a USD 
cash account, but also that your broker purchases these US stocks in US 
dollars, which are converted from your Canadian dollars. The broker 
holds USD on your behalf, even if it is only transitory.


So, I suggest that you reflect that in your account hierarchy. Have an 
asset account in CAD which corresponds to your CAD cash and all 
CAD-denominated securities, and another asset account in USD which 
corresponds to your transitory USD cash and all USD-denominated securities:


-CAD Investments (parent account)
   -Online Broker Cash Account (CAD)
    -"individual CAD stocks" (in CAD)
    -etc (in USD)

-USD Investments (parent account)
  -Online Broker Cash Account (USD)    # note: transitory cash holdings
  -AAPL stock (in USD)
  -AMZN stock (in USD)
  -etc (in USD)

Does your broker report the USD prices of your US stock purchases, e.g. 
N shares at X USD per share?  Than N*X = Y USD total purchase price, and 
your broker deducted Z CAD to fund the purchase, so that they are 
implicitly exchanging Z CAD: Y USD. Each time you buy or sell shares, 
the Online Broker Cash Account (USD) will see a cash balance from the 
purchase or sale, together with an offsetting USD:CAD exchange 
transaction which brings that Cash Account (USD) balance back to zero.


Best regards,
  —Jim DeLaHunt, Vancouver, B.C.

On 2023-01-07 09:56, Karl wrote:

Thanks, John.

I am a self-directed investor, using an online broker. My structure would
be something like this:

Bank account ---> transfer funds to ---> online broker cash account (all in
CAD $) > all my investments


I then use my single online broker cash account to purchase my investments
(Canadian stocks, American stocks, etc.). If I purchase foreign stocks
(foreign to Canada), my broker automatically converts my CAD "broker cash
account" to USD to purchase the stock. There is no need for me to have two
broker cash accounts (one for CAD and one for USD) - all my investment cash
is kept in one account, in CAD.

Does that make sense? Hopefully I'm being clear.

So maybe I could set up my GnuCash Investment hierarchy something like:

-Online Broker Cash Account (all in CAD)

-USD Investments (parent account)

-AAPL stock

-AMZN stock

-etc

-CAD Investments (parent account)

-"individual CAD stocks"

-etc


Would that work?

Regards,

*Karl*


On Fri, 6 Jan 2023 at 23:22, john  wrote:


GnuCash prioritizes direct prices over indirect ones, so if you have a
single AAPL-CAD price in your price database and a bunch of AAPL-USD and
USD-CAD ones the latter will be ignored when trying to price AAPL in CAD
and you'll almost always get the single direct price.

Two more important considerations: Every transaction in GnuCash has a
single transaction currency and all prices created by that transaction are
to/from the transaction currency. The transaction currency is determined by
the account whose register has focus when you create it or by the From
account when using the Transfer Dialog.

If you're going to do multi-currency trading you want to enable Trading
Accounts on the book. You do that on the first tab of File>Properties. One
of the side effects of doing that is that the register shows amounts in the
split account's currency instead of the Register account's currency. The
following example will be written that way.

To avoid creating that AAPL-CAD price you need to create a possibly fake
USD cash account. If you purchase of US stocks involve an actual USD cash
account then use that. Once the accounts are in place, do the following.
For an e.g. to have numbers I'll assume a purchase of 100 shares of AAPL at
today's closing price of 129.62 and 1 USD = 1.34429 CAD. 100 shares of
AAPL, assuming a no-fee/no-commission brokerage and that the ask is the
close, will cost USD 12,962.00, which is CAD 17,433.24. If you do this part
from the CAD account you must use two transactions like so:

2023-01-06 Fund USD Cash for Purchase of 100 AAPL
Assets:Investment:Cash-CAD CAD 17,433.24
Assets:Investment:Cash-USD USD 12,962.00

Now buy the stock in another transaction. Do this in either the AAPL or
USD register to ensure that the transaction currency is USD!
2023-01-06 Buy AAPL 100
Assets:Investment:Stocks:Stocks-USD:AAPL 100 129.62 12,1962.00
Assets:Investment:Cash-USD 12,962.00

If you start from the AAPL or Cash-USD account you can do it in a single
transaction because the transaction currency will be USD, but you still
need to do all four splits. Note that when you 

Re: [GNC] Variables in Scheduled transactions

2023-01-07 Thread Stan Brown (using GC 2.6.19)


> On 1/7/23 12:23 PM, Stan Brown (using GC 2.6.19) wrote:
>> Update -- 2.6.19 does prompt only once per variable, after all.
>>
>> I thought it did, because, when the transaction fires, the UI for
>> prompting for an amount and accepting is pretty confusing (to me,
>> anyway). I entered the amount and clicked the OK button, but was
>> immediately prompted again for the same variable. By
>> experimentation I found that I have to press Enter after entering
>> the amount, and _then_ click OK. (I'm using 2.6.19, so maybe the
>> interface is a little clearer in later versions.
On 2023-01-07 15:04, Adrien Monteleone wrote:
> Glad to hear you got it squared away.
> 
> I'm not sure if this has to do with my SX preferences, but I no longer
> get a pop-up window for variables. There is an entry field in the Since
> Last Run dialog to enter them. (which I have to Tab out of to commit)
> That may have been implemented after 2.6.19 though. I haven't used
> variables in several years to notice when the change happened.

Not quite sure what you're seeing, or whether I see the same thing, but
there is a field in the dialog that pops up when I click Since Last Run.

But to commit that amount, I have to press Enter. When I enter an amount
in that field and press Tab, _another_ field opens in the dialog, lower
down, but the amount I enter there seems to just get thrown away.

I'm not asking for any kind of troubleshooting on this, because I now
know how to commit the values of variables. I'm just responding to let
you know that the value field in Since Last Run dates back at least to
2.6.19, though some details may differ from the present UI.

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Request for Automatic Reconciliation Function

2023-01-07 Thread Bite Gao

GnuCash Developers and Maintainers:
  Thanks for your suggestion.

  Yours,

Bite Gao
Jan 8th, 2023


On 2023/1/8 6:30, Gyle McCollam wrote:

I agree John, this is as close as you need to get to automatic reconciliation.  
The only items you need to look at are the ones that don't match and Gnucash 
would have no way of knowing what is correct.


Thank You,

Gyle McCollam

Gyle McCollam

gmccol...@live.com   email


From: gnucash-user  on behalf of 
John Layman 
Sent: Saturday, January 7, 2023 10:35 AM
To: 'Jim DeLaHunt' ; gnucash-user@gnucash.org 

Subject: Re: [GNC] Request for Automatic Reconciliation Function

GnuCash already provides the nearest thing resembling "automatic" reconciliation.  It 
requires periodically downloading and importing account activity from the bank to mark which 
transactions have 'cleared'.  Then, in reconciliation, GnuCash automatically 'ticks' the cleared 
transactions.  Nine times out of ten in my experience, this reconciles the account with the bank 
statement.  There is no logical way to "automagically" reconcile discrepancies.

-Original Message-
From: gnucash-user  On 
Behalf Of Jim DeLaHunt
Sent: Friday, January 6, 2023 8:35 PM
To: gnucash-user@gnucash.org
Subject: Re: [GNC] Request for Automatic Reconciliation Function

Bite Gao:

Thank you for continuing this conversation. I am glad to have your ideas in 
this discussion.

While I think I understand what feature you are asking for, I do see some 
difficulties with it. For example, you say:

On 2023-01-06 17:22, Bite Gao wrote:

…For each split record in the GnuCash file, the program scan for its
counterpart in the bank statement.… Personally, I do not found that
how computer program could make mistake in this process.…

The obvious difficulty is that for a single transaction, the text in the GnuCash file is probably 
different than the text in its counterpart in the bank statement. For example, suppose I have a 
weekly purchase where I enter the description as "SPUD, Vancouver BC" and the date as 
January 5, but the bank statement may say "Small Potatoes Delivery * Paypal" and the date 
as January 6.  It is difficult — not impossible, but difficult — for GnuCash to see that these two 
transactions are counterparts. Their description text and their dates differ.

It turns out that GnuCash's Import Matcher can successfully recognise the link 
between these two.  But it often makes mistakes in this process.

Best regards,
  —Jim DeLaHunt


On 2023-01-06 17:22, Bite Gao wrote:

GnuCash Developers and Maintainers:
   Hello! While you pinpoint out the possibility of a mistake in
automated process, it did not eliminate the meaning of the automatic
reconciliation.
   What an automatic reconciliation does is: the program concatenates
the transaction's date, check number and the transaction amount from
both the bank statement and the GnuCash file. For each split record in
the GnuCash file, the program scan for its counterpart in the bank
statement. And when the counterpart is found, the program marks the
split as reconciled.
   Personally, I do not found that how computer program could make
mistake in this process. If you believe that the computer could have
that happen, I would like to learn the detail about it.

   Yours,

Bite Gao
Jan 7th, 2021

On 2023/1/6 20:57, Adrien Monteleone wrote:


I understand your explanation, but if you aren't checking and
verifying every transaction, how do you ever discover when the
automated process makes a mistake?

Reconciliation was invented long before computers, but I appreciate
that the process demands one to slow down, take your time, and
methodically verify the information.

Think of it as proof-reading - the hard way. (I learned in school to
read stuff backwards when proofing!)

That is a pretty good analogy too:

If you've ever used auto-correct with auto-checking for spelling and
grammar, or auto-suggestion or auto-completion for entire words and
have seen the embarrassment and/or nightmare that can produce when
the computer 'gets it wrong', would you want something like that for
your financial records?

Regards,
Adrien

On 1/5/23 7:50 PM, Bite Gao wrote:

GnuCash Developers and Maintainers:
Hello! While you have mentioned the requirement of human
intervene in the reconciliation process, I do not see it contradicts
with the presence of automatically reconciliation system.
In a reconcile process, the accountant check the record in the
account book with the record in the bank statement (or statement
from other institution). He (or she) may found out that two record
are identical, or he (or she) may found that some record are not
identical. Only the latter requires human notice, since there its no
point wasting time on reconciled accounting transactions. An
automatic reconciliation system can load the digital statement from
the institution, compares the statement with the transaction in 

Re: [GNC] OFX Requirements

2023-01-07 Thread ml
I’ll check it out. Thanks.

> On Jan 7, 2023, at 17:54, Jean L  wrote:
> 
> Also, this
> 
> https://github.com/jrwrigh/csv2cash <https://github.com/jrwrigh/csv2cash>
> Could be the answer to what you're trying to do?
> 
> Jean
> 
> On 1/7/2023 12:51 PM, Tim Rohrer wrote:
>> 
>> 
>>> On Jan 7, 2023, at 2:32 PM, Jean L  
>>> <mailto:rip...@gmail.com> wrote:
>>> 
>>> 
>>> OK so I found that GC fais to import this ofx because the account name is 
>>> too long. This is probably a bug, but I'm not sure what the specs are for 
>>> account names in the OFX specifications.
>>> 
>> Nice find! Thank you. So yeah, `csv2ofx` generates those randomly. Why the 
>> author made them so long is a little unclear; maybe the same code as the 
>> autogenerated FITD?
>>> About the rest of your questions:
>>> 
>>> You're right that you can't specify the "other" account (like 
>>> expense:dining) in the OFX file. That's specifically a GC thing. When you 
>>> import your OFX, you have to specify the "other" account for each 
>>> transaction, but GC learns to automatically assign it after a little while 
>>> so you no longer have to assign it manually.
>>> 
>>> In your case it's not super helpful if you save *all* your migrated 
>>> transactions into a single OFX then try to import that in one shot you'll 
>>> have to specify the other account for each transaction, which would be 
>>> super tedious.
>>> 
>>> Instead, you could import only the first N transactions, the re-import and 
>>> deals with the N next ones, etc. Each time you import, GC learns the 
>>> association between transactions and splits. But that too could be tedious.
>>> 
>>> Perhaps you can make it work better with the CSV idea. Even better would be 
>>> to write a script that takes the CSV export, and generates the complete xml 
>>> file that GC uses to represent your account tree. I.e., a tool to 
>>> automatically create a GC account file from a csv export. Perhaps 
>>> somebody's written that already?
>>> 
>> 
>> This last idea is exactly what I was starting to think about. I don't know 
>> C/C++, but I can figure out XML. And I've not done a lot of Internet 
>> searching yet for others who've worked this migration (other than in our 
>> mailing list). 
>> 
>> Again, thank you!
>> 
>> Tim
>> 
>>> Jean
>>> 
>>> On 1/7/2023 10:59 AM, Tim Rohrer wrote:
>>>> Correct. And the errors and warnings I pasted earlier are logged.
>>>> 
>>>> Linux GnuCash 4.11
>>>> Build ID: 4.11+(2022-06-25)
>>>> 
>>>>> On Jan 7, 2023, at 12:53 PM, Jean L  
>>>>> <mailto:rip...@gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> And you're saying that when you import this into a blank account, nothing 
>>>>> shows up?
>>>>> 
>>>>> On 1/7/2023 10:52 AM, Tim Rohrer wrote:
>>>>>> Thanks, Jean.
>>>>>> 
>>>>>> Here is the entire file (attached and pasted). For testing, I was simply 
>>>>>> trying to get one transaction to work first.
>>>>>> 
>>>>>> 
>>>>>> DATA:OFXSGML <>
>>>>>> ENCODING:UTF-8
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 0
>>>>>> INFO
>>>>>> 
>>>>>> 20230107105800
>>>>>> ENG
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 0
>>>>>> INFO
>>>>>> 
>>>>>> 
>>>>>> USD
>>>>>> 
>>>>>> b9fc6ca936ba09958d5076dd5ebfac69
>>>>>> 384d7d0b77b259606be9c29de2e05b45
>>>>>> CHECKING
>>>>>> 
>>>>>> 
>>>>>> 19700101
>>>>>> 20230107
>>>>>> 
>>>>>> CREDIT
>>>>>> 2022010100
>>>>>> 500.00
>>>>>> 743df964dc21309d6d8a7c0ca5eaa657
>>>>>> Tim
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>&

Re: [GNC] reconcile dates

2023-01-07 Thread Adrien Monteleone

Is this an account of type Credit Card by chance?

Regards,
Adrien

On 1/7/23 6:08 PM, Kevin T via gnucash-user wrote:

OK.   getting that off the plate.
When i do a reconcile, change the date to the previous reconcile datae, and the 
balances match, with no manipulations, when I click the finish button, a funds 
transfer form pops up!
I saved, exitted, restarted and this behavior is consistent.
Is that considered normal?


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread Kevin T via gnucash-user
OK.   getting that off the plate.
When i do a reconcile, change the date to the previous reconcile datae, and the 
balances match, with no manipulations, when I click the finish button, a funds 
transfer form pops up!  
I saved, exitted, restarted and this behavior is consistent.
Is that considered normal?
Kevin 

On Saturday, January 7, 2023 at 02:54:44 PM CST, David T. 
 wrote:  
 
 Your records and the bank's differ. The reconciliation date may include 
entries that you've entered with later dates, and how would GnuCash determine 
the proper cutoff? 

Personally, I don't have trouble determining when the difference figure goes to 
0.

David T. On Jan 7, 2023, at 11:45 PM, Kevin T via gnucash-user 
 wrote:
Is there some reason that the reconcile feature looks past the closing date 
specified?
I have imported numerous months of transactions for an account.  Trying to 
reconcile only the first month with 0 balance and 0 transactions before the 
starting date.  I provide the 'statement date' to the reconcile feature and it 
brings up every transaction entered, even the ones after the 'statement date'.  
This is not how a person would reconcile this.  We could concern ourselves with 
on the transactions that occur before the closing date 'statement date'.
Is there something I am missing ?
Kevin

gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Jean L

Also, this

https://github.com/jrwrigh/csv2cash

Could be the answer to what you're trying to do?

Jean

On 1/7/2023 12:51 PM, Tim Rohrer wrote:




On Jan 7, 2023, at 2:32 PM, Jean L  wrote:


OK so I found that GC fais to import this ofx because the account 
name is too long. This is probably a bug, but I'm not sure what the 
specs are for account names in the OFX specifications.


Nice find! Thank you. So yeah, `csv2ofx` generates those randomly. Why 
the author made them so long is a little unclear; maybe the same code 
as the autogenerated FITD?


About the rest of your questions:

You're right that you can't specify the "other" account (like 
expense:dining) in the OFX file. That's specifically a GC thing. When 
you import your OFX, you have to specify the "other" account for each 
transaction, but GC learns to automatically assign it after a little 
while so you no longer have to assign it manually.


In your case it's not super helpful if you save *all* your migrated 
transactions into a single OFX then try to import that in one shot 
you'll have to specify the other account for each transaction, which 
would be super tedious.


Instead, you could import only the first N transactions, the 
re-import and deals with the N next ones, etc. Each time you import, 
GC learns the association between transactions and splits. But that 
too could be tedious.


Perhaps you can make it work better with the CSV idea. Even better 
would be to write a script that takes the CSV export, and generates 
the complete xml file that GC uses to represent your account tree. 
I.e., a tool to automatically create a GC account file from a csv 
export. Perhaps somebody's written that already?




This last idea is exactly what I was starting to think about. I don't 
know C/C++, but I can figure out XML. And I've not done a lot of 
Internet searching yet for others who've worked this migration (other 
than in our mailing list).


Again, thank you!

Tim


Jean

On 1/7/2023 10:59 AM, Tim Rohrer wrote:

Correct. And the errors and warnings I pasted earlier are logged.

Linux GnuCash 4.11
Build ID: 4.11+(2022-06-25)


On Jan 7, 2023, at 12:53 PM, Jean L  wrote:


And you're saying that when you import this into a blank account, 
nothing shows up?


On 1/7/2023 10:52 AM, Tim Rohrer wrote:

Thanks, Jean.

Here is the entire file (attached and pasted). For testing, I was 
simply trying to get one transaction to work first.



DATA:OFXSGML
ENCODING:UTF-8




0
INFO

20230107105800
ENG






0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim









On Jan 7, 2023, at 12:41 PM, Jean L  wrote:


Can you post a small OFX file that's generated that way? I'll take a
quick look.

Jean

On 1/7/2023 10:18 AM, Tim Rohrer wrote:
I'm continuing my experimentation to migrate my Quicken for Mac 
data. I believe I'm on track for the investments, so I've 
switched back to regular accounts.


Originally, I was going to use the Quicken Mac 2007 Transfer 
File (QMTF aka QIF) but I started seeing some issues with how 
GnuCash handles splits, plus I'd lose tags and much of my notes.


Now I'm trying to usehttps://github.com/reubano/csv2ofx 
<https://github.com/reubano/csv2ofx> to generate OFX files from 
exported csv.


A dummy csv transaction:

Date,Payee/Security,Category,Amount,Account
1/1/2022,Tim,Income:Salary,500,Family Checking

Using csv2ox with a custom mapper, I get an ofx with guts of the 
transaction like this:





0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim





But nothing appears to import.

In my logs:

LibOFX INFO: libofx_proc_file(): File format not specified, 
autodetecting...

(Above message occurred on Line 40, Column 1)
LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open 
Financial eXchange (OFX or QFX))

(Above message occurred on Line 40, Column 1)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate SIGNONMSGSRSV1

(Above message occurred on Line 2, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate SONRS

(Above message occurred on Line 3, Column 3)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate BANKMSGSRSV1

(Above message occurred on Line 12, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate STMTTRNRS

(Above message occurred on Line 13, Column 3)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date 
part, but unable to parse time part of string 19700101. It is 
not in proper MMDDHHMMSS.XXX[gmt offset:tz name] format!

(Above message occurred on Line 27, Column 23)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date 
part, but unable to parse time part of string 20230107. It is 
not in proper MMDDHHMMSS.XXX[

Re: [GNC] reconcile dates

2023-01-07 Thread Adrien Monteleone

Another alternative:

Import one month
Reconcile
Repeat

-
But I'll add another case for including later transactions:

-For whatever reason, you entered them for a later date than they really 
occurred.


If they aren't visible, you'll think they are missing and then enter 
them againor enter a balancing transaction, either of which would be 
unnecessary and have to be fixed later anyway.


Regards,
Adrien

On 1/7/23 4:58 PM, David H wrote:

Personally I like it just the way it is as I want to see a full picture of
my account when reconciling and I don't usually have a lot of future
dated txns.  I think the OP's issue is that he's not doing just another
monthly reconciliation, he's trying to reconcile months and months of
imported txns starting at month 1.  If I were him I'd be taking a different
approach and attempting the reconciliations in reverse, forgetting any
starting balance discrepancy as it's really the closing balance that is
important. All going well the latest reconciliation would match, all txns
would be matched as reconciled and the job is done and the starting balance
should agree with the next bank statement.  Failing that I'd just keep
working backwards until I had a closing balance that matched, then start
working forwards again on a monthly basis investigating any closing balance
mismatches and sorting them out as required.


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread David Reiser via gnucash-user
True, and sometimes I move the transaction to the actual month. But if it’s 
supposed to happen in the future, and happens now instead, if gnucash isn’t 
showing me pending transactions after the closing date, then reconciling is 
harder because I won’t get the reminder that the credit union was early in my 
favor.
--
Dave Reiser
dbrei...@icloud.com





> On Jan 7, 2023, at 5:50 PM, Gyle McCollam  wrote:
> 
> Technically, if your credit union credits the January payment in December and 
> you have access to  the money in December it should be credited in your books 
> in December, not January.  However, if you enter it as January in your books, 
> I can see why you would need to have Gnucash look past the end date.  This 
> happens to me as well, but I record the transaction in the month it happens, 
> not when it is supposed to happen. 
> 
> Thank You,   
> Gyle McCollam
> Gyle McCollam
> gmccol...@live.com    email
> From: David Reiser mailto:dbrei...@icloud.com>>
> Sent: Saturday, January 7, 2023 5:43 PM
> To: Gyle McCollam mailto:gmccol...@live.com>>
> Cc: Kevin T mailto:neviki...@yahoo.com>>; David T. 
> mailto:sunfis...@yahoo.com>>; Gnucash Users 
> mailto:gnucash-user@gnucash.org>>
> Subject: Re: [GNC] reconcile dates
>  
> My credit union activates deposits for my account when received. Deposits 
> from outside that are intended for the first of the month are usually 
> credited in the prior month. When that happens, I need gnucash to look beyond 
> the end of the month for the transaction that represents a January payment 
> credited in December, or my reconciliation will fail.
> --
> Dave Reiser
> dbrei...@icloud.com 
> 
> 
> 
> 
> 
>> On Jan 7, 2023, at 5:27 PM, Gyle McCollam > > wrote:
>> 
>> I to don't see the need to include transactions whose date falls beyond the 
>> closing date of the reconciliation.  Gnucash could cutoff any transactions 
>> whose date is after the closing date.  However, I will say that I have 
>> gotten used to this little quirk and since I import most of my monthly 
>> transactions (and the financial institution knows how to cut off 
>> transactions beyond the closing date) using QFX, when I reconcile the needed 
>> transactions have already been checked and the ones after the closing have 
>> not.  Even though in a manual reconciliation you wouldn't even look at 
>> transactions after the closing date, it does no harm to include them.
>> 
>> 
>> Thank You,
>> 
>> Gyle McCollam
>> 
>> Gyle McCollam
>> 
>> gmccol...@live.com 
>>    email
>> 
>> 
>> From: gnucash-user > > on behalf of 
>> David T. via gnucash-user > >
>> Sent: Saturday, January 7, 2023 3:54 PM
>> To: Kevin T mailto:neviki...@yahoo.com>>
>> Cc: Gnucash Users > >
>> Subject: Re: [GNC] reconcile dates
>> 
>> Your records and the bank's differ. The reconciliation date may include 
>> entries that you've entered with later dates, and how would GnuCash 
>> determine the proper cutoff?
>> 
>> Personally, I don't have trouble determining when the difference figure goes 
>> to 0.
>> 
>> ⁣David T. ​
>> 
>> On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
>> mailto:gnucash-user@gnucash.org>> wrote:
>>> Is there some reason that the reconcile feature looks past the closing
>>> date specified?
>>> I have imported numerous months of transactions for an account.  Trying
>>> to reconcile only the first month with 0 balance and 0 transactions
>>> before the starting date.  I provide the 'statement date' to the
>>> reconcile feature and it brings up every transaction entered, even the
>>> ones after the 'statement date'.
>>> This is not how a person would reconcile this.  We could concern
>>> ourselves with on the transactions that occur before the closing date
>>> 'statement date'.
>>> Is there something I am missing ?
>>> Kevin
>>> ___
>>> gnucash-user mailing list
>>> gnucash-user@gnucash.org 
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> -
>>> 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@gnucash.org 
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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
>> 

Re: [GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Adrien Monteleone

Yes, the principle of Materiality.

It isn't worth spending time looking for small errors. Just adjust them 
out and move on.


Otherwise, I'd say enter the transaction on what you think is the proper 
date and re-reconcile.


But that begs the question, how did you reconcile without it?

If you had to make an adjusting entry, that will also need to be edited 
or deleted.


-
I always understood Petty Cash to be for incidental expenses that didn't 
necessarily need to be tracked in dedicated accounts. The physical funds 
were usually accessible without issuing a check to pay for them from a 
comptroller. But it is still 'reconciled' to cash receipts for 
purchases/payments.


They aren't necessarily 'immaterial' but merely listed as 'other expenses'.

Regards,
Adrien

On 1/7/23 3:14 PM, Geoff wrote:

Minor Transactions
Accountants may sometimes deem minor transactions to be immaterial. This 
may happen when a financial controller is attempting to close the books 
for a particular accounting period. Accountants can choose to omit minor 
transactions from the final calculations if they would have an 
immaterial impact on the overall financial statements.


https://uk.indeed.com/career-advice/career-development/materiality-in-accounting

So, do whatever works efficiently for you.  The time you spend 
contemplating the "correct" date for a 60p transaction is far better 
spent on what you do best - running your business.


(Not so long ago this would have been accounted for out of a bucket 
called "petty cash" and reconciled once every month or so.)


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Variables in Scheduled transactions

2023-01-07 Thread Adrien Monteleone

Glad to hear you got it squared away.

I'm not sure if this has to do with my SX preferences, but I no longer 
get a pop-up window for variables. There is an entry field in the Since 
Last Run dialog to enter them. (which I have to Tab out of to commit) 
That may have been implemented after 2.6.19 though. I haven't used 
variables in several years to notice when the change happened.


Regards,
Adrien

On 1/7/23 12:23 PM, Stan Brown (using GC 2.6.19) wrote:

Update -- 2.6.19 does prompt only once per variable, after all.

I thought it did, because, when the transaction fires, the UI for
prompting for an amount and accepting is pretty confusing (to me,
anyway). I entered the amount and clicked the OK button, but was
immediately prompted again for the same variable. By experimentation I
found that I have to press Enter after entering the amount, and _then_
click OK. (I'm using 2.6.19, so maybe the interface is a little clearer
in later versions.)

Now that I understand how the interface works, I have set up my mortgage
payment transaction as described below, and tested it successfully with
"Since Last Run".


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Budget report fails in multiple currencies

2023-01-07 Thread Adrien Monteleone

As long as the change in value isn't cumulative, I would want to know.

If I wanted to budget the same 'purchasing power' as last period/year, I 
would not want to budget the exact same nominal amount. (on that note, a 
feature to factor inflation for budgets would be swell!)


But I do understand that previous rates are no guarantee of future 
rates. (exchange or inflation) They provide a starting point though.


All of that would only affect my *next* budget, via Actual, not the 
current one. (it might also explain Variance) So I still think there's a 
potential bug.


Regards,
Adrien

On 1/7/23 11:35 AM, ml enquirer wrote:

Hi Fred,

Thanks for the thought! I agree the change in value is 10,000. My point is,
basically, that I don't care about currency fluctuations in money already
spent when planning *next* year's budget.

But the 'problem' (which might just be that I need someone to explain what
a 'budget' is!) is (at least) two fold:
1) When I think 'budget' I think "planning how much I can spend in this
budget period". So I want the report to tell me that. If there are no
transactions in any child account, I don't expect a non-zero total in the
parent account. I certainly don't want a non-zero total that depends how
long I've been using gnucash. In the first year of using Gnucash, this
shows the total expense. In the 100th (hopefully!) year of using Gnucash,
this mainly shows the currency fluctuation of the history of my grocery
spending in years 0-99! These are totally different things, at least for
the typical use of an expense account like 'groceries'.
2) The budget report and the budget view seem to show the totals
aggregating in different ways. I would expect correspondence.

When you think "budgetting this year's groceries", why would you care about
having to plan for the currency fluctuation in what has already been spent,
and which is no longer available to spend, and which has no impact on what
can be spent this year? Is there another report that you'd recommend that I
use?

Let me be gently provocative: I think my described use-case is more widely
relevant, at least for expense accounts if not for asset accounts ;) But as
I keep on saying, I'm very ignorant of even basic accountancy techniques,
so feel free to (gently) teach me!


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread David H
Personally I like it just the way it is as I want to see a full picture of
my account when reconciling and I don't usually have a lot of future
dated txns.  I think the OP's issue is that he's not doing just another
monthly reconciliation, he's trying to reconcile months and months of
imported txns starting at month 1.  If I were him I'd be taking a different
approach and attempting the reconciliations in reverse, forgetting any
starting balance discrepancy as it's really the closing balance that is
important. All going well the latest reconciliation would match, all txns
would be matched as reconciled and the job is done and the starting balance
should agree with the next bank statement.  Failing that I'd just keep
working backwards until I had a closing balance that matched, then start
working forwards again on a monthly basis investigating any closing balance
mismatches and sorting them out as required.

Cheers David H.


On Sun, 8 Jan 2023 at 08:44, David Reiser via gnucash-user <
gnucash-user@gnucash.org> wrote:

> My credit union activates deposits for my account when received. Deposits
> from outside that are intended for the first of the month are usually
> credited in the prior month. When that happens, I need gnucash to look
> beyond the end of the month for the transaction that represents a January
> payment credited in December, or my reconciliation will fail.
> --
> Dave Reiser
> dbrei...@icloud.com
>
>
>
>
>
> > On Jan 7, 2023, at 5:27 PM, Gyle McCollam  wrote:
> >
> > I to don't see the need to include transactions whose date falls beyond
> the closing date of the reconciliation.  Gnucash could cutoff any
> transactions whose date is after the closing date.  However, I will say
> that I have gotten used to this little quirk and since I import most of my
> monthly transactions (and the financial institution knows how to cut off
> transactions beyond the closing date) using QFX, when I reconcile the
> needed transactions have already been checked and the ones after the
> closing have not.  Even though in a manual reconciliation you wouldn't even
> look at transactions after the closing date, it does no harm to include
> them.
> >
> >
> > Thank You,
> >
> > Gyle McCollam
> >
> > Gyle McCollam
> >
> > gmccol...@live.com   email
> >
> > 
> > From: gnucash-user 
> on behalf of David T. via gnucash-user 
> > Sent: Saturday, January 7, 2023 3:54 PM
> > To: Kevin T 
> > Cc: Gnucash Users 
> > Subject: Re: [GNC] reconcile dates
> >
> > Your records and the bank's differ. The reconciliation date may include
> entries that you've entered with later dates, and how would GnuCash
> determine the proper cutoff?
> >
> > Personally, I don't have trouble determining when the difference figure
> goes to 0.
> >
> > ⁣David T. ​
> >
> > On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user <
> gnucash-user@gnucash.org> wrote:
> >> Is there some reason that the reconcile feature looks past the closing
> >> date specified?
> >> I have imported numerous months of transactions for an account.  Trying
> >> to reconcile only the first month with 0 balance and 0 transactions
> >> before the starting date.  I provide the 'statement date' to the
> >> reconcile feature and it brings up every transaction entered, even the
> >> ones after the 'statement date'.
> >> This is not how a person would reconcile this.  We could concern
> >> ourselves with on the transactions that occur before the closing date
> >> 'statement date'.
> >> Is there something I am missing ?
> >> Kevin
> >> ___
> >> gnucash-user mailing list
> >> gnucash-user@gnucash.org
> >> To update your subscription preferences or to unsubscribe:
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> -
> >> 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@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > 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@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by 

Re: [GNC] Where do I set the "Accounting Period" for reports?

2023-01-07 Thread Adrien Monteleone

On 1/7/23 3:41 AM, Chris Green wrote:

I really don't want or need to save reports, it's just one more bit of
configuration that I'd need to keep track of.  I want things to be
configured in as few places as possible.


Unfortunately, that's as few steps as you can get right now.

Note, Saved Configs aren't saved *instances* of Reports. They are a 
collection of saved Options.



A saved report is of little use the next year (wrong headings often).


Then don't put that period-specific info in the config. Do that after 
you run it. (you're having to do it now anyway...)


I used a Saved Config for 'EOY Income Statement'. After it is visible, I 
make period-specific changes as needed like if I want a custom header 
text. But the bulk of the report Options are already set with the least 
amount of work.



What I want is to set things up so that whenever I click on (for
example) Transaction Report I just get that and not have to jump
through several hoops to actually get any meaningful output.


That report is an entirely different beast than Income Statement or 
Balance Sheet, the traditional annual reports.


It is a 'Swiss Army Knife' of reports, which is why you have to 
customize it to your liking each time. If you have a complicated Options 
setup for it, then of course, save that as a Config, then after you run 
it, set the period-specific stuff after.


-
You have 2 options:

1. Set the report options each and every report run. (lots of work and 
clicks)


2. Set the report options that are common *regardless of period* and 
save that as a config, then when you run the report, adjust the period 
specific options. (less work and clicks)


*dates should be generalized in a config, and with some thought when 
setting them, should in most cases, likely not need changing when 
actually run to get it right. I only specify exact dates when the 
general options aren't suitable.


-
If you'd like, craft a Transaction Report you're frustrated with, choose 
the option on the General tab to include the Options Summary and 
copy/paste that in a reply. I'll be happy to indicate which ones can be 
set in a config to save you repetitive work and get you a 'meaningful 
output' with the least amount of period-specific customization.



Regards,
Adrien

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread Gyle McCollam
Technically, if your credit union credits the January payment in December and 
you have access to  the money in December it should be credited in your books 
in December, not January.  However, if you enter it as January in your books, I 
can see why you would need to have Gnucash look past the end date.  This 
happens to me as well, but I record the transaction in the month it happens, 
not when it is supposed to happen.


Thank You,

Gyle McCollam

Gyle McCollam

gmccol...@live.com   email


From: David Reiser 
Sent: Saturday, January 7, 2023 5:43 PM
To: Gyle McCollam 
Cc: Kevin T ; David T. ; Gnucash 
Users 
Subject: Re: [GNC] reconcile dates

My credit union activates deposits for my account when received. Deposits from 
outside that are intended for the first of the month are usually credited in 
the prior month. When that happens, I need gnucash to look beyond the end of 
the month for the transaction that represents a January payment credited in 
December, or my reconciliation will fail.
--
Dave Reiser
dbrei...@icloud.com





On Jan 7, 2023, at 5:27 PM, Gyle McCollam  wrote:

I to don't see the need to include transactions whose date falls beyond the 
closing date of the reconciliation.  Gnucash could cutoff any transactions 
whose date is after the closing date.  However, I will say that I have gotten 
used to this little quirk and since I import most of my monthly transactions 
(and the financial institution knows how to cut off transactions beyond the 
closing date) using QFX, when I reconcile the needed transactions have already 
been checked and the ones after the closing have not.  Even though in a manual 
reconciliation you wouldn't even look at transactions after the closing date, 
it does no harm to include them.


Thank You,

Gyle McCollam

Gyle McCollam

gmccol...@live.com   email


From: gnucash-user  on 
behalf of David T. via gnucash-user 
Sent: Saturday, January 7, 2023 3:54 PM
To: Kevin T 
Cc: Gnucash Users 
Subject: Re: [GNC] reconcile dates

Your records and the bank's differ. The reconciliation date may include entries 
that you've entered with later dates, and how would GnuCash determine the 
proper cutoff?

Personally, I don't have trouble determining when the difference figure goes to 
0.

⁣David T. ​

On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
 wrote:
Is there some reason that the reconcile feature looks past the closing
date specified?
I have imported numerous months of transactions for an account.  Trying
to reconcile only the first month with 0 balance and 0 transactions
before the starting date.  I provide the 'statement date' to the
reconcile feature and it brings up every transaction entered, even the
ones after the 'statement date'.
This is not how a person would reconcile this.  We could concern
ourselves with on the transactions that occur before the closing date
'statement date'.
Is there something I am missing ?
Kevin
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread David Reiser via gnucash-user
My credit union activates deposits for my account when received. Deposits from 
outside that are intended for the first of the month are usually credited in 
the prior month. When that happens, I need gnucash to look beyond the end of 
the month for the transaction that represents a January payment credited in 
December, or my reconciliation will fail.
--
Dave Reiser
dbrei...@icloud.com





> On Jan 7, 2023, at 5:27 PM, Gyle McCollam  wrote:
> 
> I to don't see the need to include transactions whose date falls beyond the 
> closing date of the reconciliation.  Gnucash could cutoff any transactions 
> whose date is after the closing date.  However, I will say that I have gotten 
> used to this little quirk and since I import most of my monthly transactions 
> (and the financial institution knows how to cut off transactions beyond the 
> closing date) using QFX, when I reconcile the needed transactions have 
> already been checked and the ones after the closing have not.  Even though in 
> a manual reconciliation you wouldn't even look at transactions after the 
> closing date, it does no harm to include them.
> 
> 
> Thank You,
> 
> Gyle McCollam
> 
> Gyle McCollam
> 
> gmccol...@live.com   email
> 
> 
> From: gnucash-user  on 
> behalf of David T. via gnucash-user 
> Sent: Saturday, January 7, 2023 3:54 PM
> To: Kevin T 
> Cc: Gnucash Users 
> Subject: Re: [GNC] reconcile dates
> 
> Your records and the bank's differ. The reconciliation date may include 
> entries that you've entered with later dates, and how would GnuCash determine 
> the proper cutoff?
> 
> Personally, I don't have trouble determining when the difference figure goes 
> to 0.
> 
> ⁣David T. ​
> 
> On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
>  wrote:
>> Is there some reason that the reconcile feature looks past the closing
>> date specified?
>> I have imported numerous months of transactions for an account.  Trying
>> to reconcile only the first month with 0 balance and 0 transactions
>> before the starting date.  I provide the 'statement date' to the
>> reconcile feature and it brings up every transaction entered, even the
>> ones after the 'statement date'.
>> This is not how a person would reconcile this.  We could concern
>> ourselves with on the transactions that occur before the closing date
>> 'statement date'.
>> Is there something I am missing ?
>> Kevin
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] reconcile dates

2023-01-07 Thread R. Victor Klassen
When I write a post dated cheque and the recipient cashed it prematurely, most 
banks these days don’t blink an eyelash.  

While rare, this is a case where a transaction dated after the reconciliation 
window needs to be included.  

Sent from my iPhone

> On Jan 7, 2023, at 5:29 PM, Gyle McCollam  wrote:
> 
> I to don't see the need to include transactions whose date falls beyond the 
> closing date of the reconciliation.  Gnucash could cutoff any transactions 
> whose date is after the closing date.  However, I will say that I have gotten 
> used to this little quirk and since I import most of my monthly transactions 
> (and the financial institution knows how to cut off transactions beyond the 
> closing date) using QFX, when I reconcile the needed transactions have 
> already been checked and the ones after the closing have not.  Even though in 
> a manual reconciliation you wouldn't even look at transactions after the 
> closing date, it does no harm to include them.
> 
> 
> Thank You,
> 
> Gyle McCollam
> 
> Gyle McCollam
> 
> gmccol...@live.com   email
> 
> 
> From: gnucash-user  on 
> behalf of David T. via gnucash-user 
> Sent: Saturday, January 7, 2023 3:54 PM
> To: Kevin T 
> Cc: Gnucash Users 
> Subject: Re: [GNC] reconcile dates
> 
> Your records and the bank's differ. The reconciliation date may include 
> entries that you've entered with later dates, and how would GnuCash determine 
> the proper cutoff?
> 
> Personally, I don't have trouble determining when the difference figure goes 
> to 0.
> 
> ⁣David T. ​
> 
>> On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
>>  wrote:
>> Is there some reason that the reconcile feature looks past the closing
>> date specified?
>> I have imported numerous months of transactions for an account.  Trying
>> to reconcile only the first month with 0 balance and 0 transactions
>> before the starting date.  I provide the 'statement date' to the
>> reconcile feature and it brings up every transaction entered, even the
>> ones after the 'statement date'.
>> This is not how a person would reconcile this.  We could concern
>> ourselves with on the transactions that occur before the closing date
>> 'statement date'.
>> Is there something I am missing ?
>> Kevin
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Is a screwed-up style sheet hiding somewhere?

2023-01-07 Thread Adrien Monteleone

On 1/7/23 8:29 AM, Dr. David Kirkby wrote:

It’s difficult for me to comprehend why that fancy template in that form
should exist at all. I don’t think anyone could consider it sane. I
reported it a bug

https://bugs.gnucash.org/show_bug.cgi?id=798717

and see it has been closed with a note that it will be fixed in the next
release.


Yep, saw the fix.


I thought that “Reset Defaults” in that part of the software would have
reset the default invoice to be the default one.


It does, but perhaps the wording somewhere could be improved.

There isn't as far as I can tell, any way to reset all Preferences 
either by tab, or entirely. The Book Properties though, does have this 
option, by tab. (It did not escape me that these are two different 
dialogs and it appears one of them, offers by default, a 'Reset 
Defaults' button that the dialog used by Preferences, does not have, 
either by design, or as an oversight.)


The place where you see 'Reset Defaults' is in the report Options 
dialog. There's a button on each tab to do so. (for that tab only)


But if you set a different 'default' report template in Preferences, 
that is fixed until you change it. (two different dialogs)


Note, the preference doesn't set a default 'stylesheet' it sets a 
default 'template' which uses *as its default* its own built-in styles. 
(not editable easily)


When you are in Report Options, that is for that particular template.

If you were to set the default template to 'Fancy' run an Invoice 
Report, change the stylesheet in Options > General to 'Easy', then click 
'Reset Defaults', the stylesheet would be reset back to 'dafault' which 
uses the built-in styles of the Fancy template.


At least, GnuCash does show you which template you are using. It's the 
name of the tab for the invoice report, unless you rename it later. And 
since it is the name of the tab, that also appears in the window's title 
bar. (for the main app if using tabs, or the report window if using 
separate windows)



Thank you. I had created an invoice with my company logo, which I would
have liked to use as a default. I will recreate that now, tweak it a bit as
I am not 100% satisfied, then save that as a default. (I was a bit
surprised that setting the width of the banner to 1” was about optimal. The
manual says one will have to experiment, but suggests 6” x 1” to be
reasonable. Clearly 6” wide is very different to 1” wide)


Sounds like another bug, but perhaps just a labeling issue, not a 
functional one. I don't even see that option though. I see places to set 
images, but other than general location, I don't see a place to set 
size. (or do you have to do that outside of GnuCash?)



Thank you for the suggestion. I would much prefer to be using a Linux
computer myself. Unfortunately the Linux computer is in my lab, which is
detached from the house. In order to use that computer I would need to run
the air conditioning to keep the room temperature comfortable, then use a
power hungry computer to use some software that uses very little CPU power
or memory. I think I should invest in a more general purpose computer. It
is very rare for me to need several hundred of GB of RAM.


Do you have network access to that machine from inside the house by 
chance? You could use VNC or RDP to remote view the Linux desktop from 
Windows. (and if you need to get fancy, set up a VM or LXD container on 
the Linux box just for GnuCash) There are even ways you can make it 
appear seamless that you are accessing a single app rather than the 
whole desktop. (it's also possible to serve that single app, but I've 
not played with such)


Regards,
Adrien

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Request for Automatic Reconciliation Function

2023-01-07 Thread Gyle McCollam
I agree John, this is as close as you need to get to automatic reconciliation.  
The only items you need to look at are the ones that don't match and Gnucash 
would have no way of knowing what is correct.


Thank You,

Gyle McCollam

Gyle McCollam

gmccol...@live.com   email


From: gnucash-user  on 
behalf of John Layman 
Sent: Saturday, January 7, 2023 10:35 AM
To: 'Jim DeLaHunt' ; gnucash-user@gnucash.org 

Subject: Re: [GNC] Request for Automatic Reconciliation Function

GnuCash already provides the nearest thing resembling "automatic" 
reconciliation.  It requires periodically downloading and importing account 
activity from the bank to mark which transactions have 'cleared'.  Then, in 
reconciliation, GnuCash automatically 'ticks' the cleared transactions.  Nine 
times out of ten in my experience, this reconciles the account with the bank 
statement.  There is no logical way to "automagically" reconcile discrepancies.

-Original Message-
From: gnucash-user  On 
Behalf Of Jim DeLaHunt
Sent: Friday, January 6, 2023 8:35 PM
To: gnucash-user@gnucash.org
Subject: Re: [GNC] Request for Automatic Reconciliation Function

Bite Gao:

Thank you for continuing this conversation. I am glad to have your ideas in 
this discussion.

While I think I understand what feature you are asking for, I do see some 
difficulties with it. For example, you say:

On 2023-01-06 17:22, Bite Gao wrote:
> …For each split record in the GnuCash file, the program scan for its
> counterpart in the bank statement.… Personally, I do not found that
> how computer program could make mistake in this process.…

The obvious difficulty is that for a single transaction, the text in the 
GnuCash file is probably different than the text in its counterpart in the bank 
statement. For example, suppose I have a weekly purchase where I enter the 
description as "SPUD, Vancouver BC" and the date as January 5, but the bank 
statement may say "Small Potatoes Delivery * Paypal" and the date as January 6. 
 It is difficult — not impossible, but difficult — for GnuCash to see that 
these two transactions are counterparts. Their description text and their dates 
differ.

It turns out that GnuCash's Import Matcher can successfully recognise the link 
between these two.  But it often makes mistakes in this process.

Best regards,
 —Jim DeLaHunt


On 2023-01-06 17:22, Bite Gao wrote:
> GnuCash Developers and Maintainers:
>   Hello! While you pinpoint out the possibility of a mistake in
> automated process, it did not eliminate the meaning of the automatic
> reconciliation.
>   What an automatic reconciliation does is: the program concatenates
> the transaction's date, check number and the transaction amount from
> both the bank statement and the GnuCash file. For each split record in
> the GnuCash file, the program scan for its counterpart in the bank
> statement. And when the counterpart is found, the program marks the
> split as reconciled.
>   Personally, I do not found that how computer program could make
> mistake in this process. If you believe that the computer could have
> that happen, I would like to learn the detail about it.
>
>   Yours,
>
>Bite Gao
> Jan 7th, 2021
>
> On 2023/1/6 20:57, Adrien Monteleone wrote:
>
>> I understand your explanation, but if you aren't checking and
>> verifying every transaction, how do you ever discover when the
>> automated process makes a mistake?
>>
>> Reconciliation was invented long before computers, but I appreciate
>> that the process demands one to slow down, take your time, and
>> methodically verify the information.
>>
>> Think of it as proof-reading - the hard way. (I learned in school to
>> read stuff backwards when proofing!)
>>
>> That is a pretty good analogy too:
>>
>> If you've ever used auto-correct with auto-checking for spelling and
>> grammar, or auto-suggestion or auto-completion for entire words and
>> have seen the embarrassment and/or nightmare that can produce when
>> the computer 'gets it wrong', would you want something like that for
>> your financial records?
>>
>> Regards,
>> Adrien
>>
>> On 1/5/23 7:50 PM, Bite Gao wrote:
>>> GnuCash Developers and Maintainers:
>>>Hello! While you have mentioned the requirement of human
>>> intervene in the reconciliation process, I do not see it contradicts
>>> with the presence of automatically reconciliation system.
>>>In a reconcile process, the accountant check the record in the
>>> account book with the record in the bank statement (or statement
>>> from other institution). He (or she) may found out that two record
>>> are identical, or he (or she) may found that some record are not
>>> identical. Only the latter requires human notice, since there its no
>>> point wasting time on reconciled accounting transactions. An
>>> automatic reconciliation system can load the digital statement from
>>> the institution, compares the statement with the transaction 

Re: [GNC] reconcile dates

2023-01-07 Thread Gyle McCollam
I to don't see the need to include transactions whose date falls beyond the 
closing date of the reconciliation.  Gnucash could cutoff any transactions 
whose date is after the closing date.  However, I will say that I have gotten 
used to this little quirk and since I import most of my monthly transactions 
(and the financial institution knows how to cut off transactions beyond the 
closing date) using QFX, when I reconcile the needed transactions have already 
been checked and the ones after the closing have not.  Even though in a manual 
reconciliation you wouldn't even look at transactions after the closing date, 
it does no harm to include them.


Thank You,

Gyle McCollam

Gyle McCollam

gmccol...@live.com   email


From: gnucash-user  on 
behalf of David T. via gnucash-user 
Sent: Saturday, January 7, 2023 3:54 PM
To: Kevin T 
Cc: Gnucash Users 
Subject: Re: [GNC] reconcile dates

Your records and the bank's differ. The reconciliation date may include entries 
that you've entered with later dates, and how would GnuCash determine the 
proper cutoff?

Personally, I don't have trouble determining when the difference figure goes to 
0.

⁣David T. ​

On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
 wrote:
>Is there some reason that the reconcile feature looks past the closing
>date specified?
>I have imported numerous months of transactions for an account.  Trying
>to reconcile only the first month with 0 balance and 0 transactions
>before the starting date.  I provide the 'statement date' to the
>reconcile feature and it brings up every transaction entered, even the
>ones after the 'statement date'.
>This is not how a person would reconcile this.  We could concern
>ourselves with on the transactions that occur before the closing date
>'statement date'.
>Is there something I am missing ?
>Kevin
>___
>gnucash-user mailing list
>gnucash-user@gnucash.org
>To update your subscription preferences or to unsubscribe:
>https://lists.gnucash.org/mailman/listinfo/gnucash-user
>-
>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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Geoff

Minor Transactions
Accountants may sometimes deem minor transactions to be immaterial. This 
may happen when a financial controller is attempting to close the books 
for a particular accounting period. Accountants can choose to omit minor 
transactions from the final calculations if they would have an 
immaterial impact on the overall financial statements.


https://uk.indeed.com/career-advice/career-development/materiality-in-accounting

So, do whatever works efficiently for you.  The time you spend 
contemplating the "correct" date for a 60p transaction is far better 
spent on what you do best - running your business.


(Not so long ago this would have been accounted for out of a bucket 
called "petty cash" and reconciled once every month or so.)



Regards

Geoff
=

On 8/01/2023 4:24 am, Dr. David Kirkby wrote:

On Sat, 7 Jan 2023 at 14:37, Maf. King  wrote:



Is the Effective Legal Tax date 6th or 19th?  Enter it to that date.  The
reconcilliation will not be affected either way.

Maf.



Certainly not the 19th, but probably not the 6th either. It was for postage
and a pickup fee. I must have cancelled the pickup and rebooked it for a
later date. So arguably it is an unknown date between the two.  

The amount is only £0.60 (< $1 USD), and nowhere near the end of the
accounting period, so I don’t think anyone is going to be too bothered
about the accuracy of the information.

I think setting it the 6th is probably best, as that’s consistent with more
than 90% of the transactions. I was concerned that it might cause problems
with reconciliation, in which case I would certainly not want to risk
problems with that.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Request for Automatic Reconciliation Function

2023-01-07 Thread John Layman
GnuCash already provides the nearest thing resembling "automatic" 
reconciliation.  It requires periodically downloading and importing account 
activity from the bank to mark which transactions have 'cleared'.  Then, in 
reconciliation, GnuCash automatically 'ticks' the cleared transactions.  Nine 
times out of ten in my experience, this reconciles the account with the bank 
statement.  There is no logical way to "automagically" reconcile discrepancies.

-Original Message-
From: gnucash-user  On 
Behalf Of Jim DeLaHunt
Sent: Friday, January 6, 2023 8:35 PM
To: gnucash-user@gnucash.org
Subject: Re: [GNC] Request for Automatic Reconciliation Function

Bite Gao:

Thank you for continuing this conversation. I am glad to have your ideas in 
this discussion.

While I think I understand what feature you are asking for, I do see some 
difficulties with it. For example, you say:

On 2023-01-06 17:22, Bite Gao wrote:
> …For each split record in the GnuCash file, the program scan for its 
> counterpart in the bank statement.… Personally, I do not found that 
> how computer program could make mistake in this process.…

The obvious difficulty is that for a single transaction, the text in the 
GnuCash file is probably different than the text in its counterpart in the bank 
statement. For example, suppose I have a weekly purchase where I enter the 
description as "SPUD, Vancouver BC" and the date as January 5, but the bank 
statement may say "Small Potatoes Delivery * Paypal" and the date as January 6. 
 It is difficult — not impossible, but difficult — for GnuCash to see that 
these two transactions are counterparts. Their description text and their dates 
differ.

It turns out that GnuCash's Import Matcher can successfully recognise the link 
between these two.  But it often makes mistakes in this process.

Best regards,
 —Jim DeLaHunt


On 2023-01-06 17:22, Bite Gao wrote:
> GnuCash Developers and Maintainers:
>   Hello! While you pinpoint out the possibility of a mistake in 
> automated process, it did not eliminate the meaning of the automatic 
> reconciliation.
>   What an automatic reconciliation does is: the program concatenates 
> the transaction's date, check number and the transaction amount from 
> both the bank statement and the GnuCash file. For each split record in 
> the GnuCash file, the program scan for its counterpart in the bank 
> statement. And when the counterpart is found, the program marks the 
> split as reconciled.
>   Personally, I do not found that how computer program could make 
> mistake in this process. If you believe that the computer could have 
> that happen, I would like to learn the detail about it.
>
>   Yours,
>
>Bite Gao
> Jan 7th, 2021
>
> On 2023/1/6 20:57, Adrien Monteleone wrote:
>
>> I understand your explanation, but if you aren't checking and 
>> verifying every transaction, how do you ever discover when the 
>> automated process makes a mistake?
>>
>> Reconciliation was invented long before computers, but I appreciate 
>> that the process demands one to slow down, take your time, and 
>> methodically verify the information.
>>
>> Think of it as proof-reading - the hard way. (I learned in school to 
>> read stuff backwards when proofing!)
>>
>> That is a pretty good analogy too:
>>
>> If you've ever used auto-correct with auto-checking for spelling and 
>> grammar, or auto-suggestion or auto-completion for entire words and 
>> have seen the embarrassment and/or nightmare that can produce when 
>> the computer 'gets it wrong', would you want something like that for 
>> your financial records?
>>
>> Regards,
>> Adrien
>>
>> On 1/5/23 7:50 PM, Bite Gao wrote:
>>> GnuCash Developers and Maintainers:
>>>Hello! While you have mentioned the requirement of human 
>>> intervene in the reconciliation process, I do not see it contradicts 
>>> with the presence of automatically reconciliation system.
>>>In a reconcile process, the accountant check the record in the 
>>> account book with the record in the bank statement (or statement 
>>> from other institution). He (or she) may found out that two record 
>>> are identical, or he (or she) may found that some record are not 
>>> identical. Only the latter requires human notice, since there its no 
>>> point wasting time on reconciled accounting transactions. An 
>>> automatic reconciliation system can load the digital statement from 
>>> the institution, compares the statement with the transaction in the 
>>> accounting book, and pinpoints the discrepancies out. Then human 
>>> accountant could step in and perform manual operations, such as 
>>> checking other vouchers, contact with banks, etc. In the situation 
>>> of single user, the automatic reconcile system have no reason to 
>>> block manu al reconciliation.
>>>Besides, when I means "human err", I means that the accountant 
>>> overlook an discrepancy and regards it as identical. People do not 
>>> spend too much time on identical records, since major 

Re: [GNC] reconcile dates

2023-01-07 Thread David T. via gnucash-user
Your records and the bank's differ. The reconciliation date may include entries 
that you've entered with later dates, and how would GnuCash determine the 
proper cutoff? 

Personally, I don't have trouble determining when the difference figure goes to 
0.

⁣David T. ​

On Jan 7, 2023, 11:45 PM, at 11:45 PM, Kevin T via gnucash-user 
 wrote:
>Is there some reason that the reconcile feature looks past the closing
>date specified?
>I have imported numerous months of transactions for an account.  Trying
>to reconcile only the first month with 0 balance and 0 transactions
>before the starting date.  I provide the 'statement date' to the
>reconcile feature and it brings up every transaction entered, even the
>ones after the 'statement date'.  
>This is not how a person would reconcile this.  We could concern
>ourselves with on the transactions that occur before the closing date
>'statement date'.
>Is there something I am missing ?
>Kevin
>___
>gnucash-user mailing list
>gnucash-user@gnucash.org
>To update your subscription preferences or to unsubscribe:
>https://lists.gnucash.org/mailman/listinfo/gnucash-user
>-
>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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Tim Rohrer
 aggregate STMTTRNRS(Above message 
occurred on Line 13, Column
 3)LibOFX WARNING: ofxdate_to_time_t():
 Successfully parsed date part, but unable to
 parse time part of string 19700101. It is not
 in proper MMDDHHMMSS.XXX[gmt offset:tz
 name] format!(Above message occurred on Line 27, Column
 23)LibOFX WARNING: ofxdate_to_time_t():
 Successfully parsed date part, but unable to
 parse time part of string 20230107. It is not
 in proper MMDDHHMMSS.XXX[gmt offset:tz
 name] format!(Above message occurred on Line 28, Column
 21)LibOFX ERROR: OpenSP parser: otherError
 (misc parse error):/tmp/libofxtmpEkcf1m:37:11:E: end 
tag for
 "STMTRS" which is not finishedI do notice there is no 
category which
 could be a problem with my customer mapper, so
 I'll keep experimenting.But, does anyone see what 
could be causing
 the error? Are the warnings of 
concern?Tim___gnucash-user mailing 
listgnucash-user@gnucash.orgTo update your subscription preferences or
 to 
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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 
listgnucash-user@gnucash.orgTo update your subscription preferences or to
   
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


[GNC] reconcile dates

2023-01-07 Thread Kevin T via gnucash-user
Is there some reason that the reconcile feature looks past the closing date 
specified?
I have imported numerous months of transactions for an account.  Trying to 
reconcile only the first month with 0 balance and 0 transactions before the 
starting date.  I provide the 'statement date' to the reconcile feature and it 
brings up every transaction entered, even the ones after the 'statement date'.  
This is not how a person would reconcile this.  We could concern ourselves with 
on the transactions that occur before the closing date 'statement date'.
Is there something I am missing ?
Kevin
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Jean L
OK so I found that GC fais to import this ofx because the account name 
is too long. This is probably a bug, but I'm not sure what the specs are 
for account names in the OFX specifications.


About the rest of your questions:

You're right that you can't specify the "other" account (like 
expense:dining) in the OFX file. That's specifically a GC thing. When 
you import your OFX, you have to specify the "other" account for each 
transaction, but GC learns to automatically assign it after a little 
while so you no longer have to assign it manually.


In your case it's not super helpful if you save *all* your migrated 
transactions into a single OFX then try to import that in one shot 
you'll have to specify the other account for each transaction, which 
would be super tedious.


Instead, you could import only the first N transactions, the re-import 
and deals with the N next ones, etc. Each time you import, GC learns the 
association between transactions and splits. But that too could be tedious.


Perhaps you can make it work better with the CSV idea. Even better would 
be to write a script that takes the CSV export, and generates the 
complete xml file that GC uses to represent your account tree. I.e., a 
tool to automatically create a GC account file from a csv export. 
Perhaps somebody's written that already?


Jean

On 1/7/2023 10:59 AM, Tim Rohrer wrote:

Correct. And the errors and warnings I pasted earlier are logged.

Linux GnuCash 4.11
Build ID: 4.11+(2022-06-25)


On Jan 7, 2023, at 12:53 PM, Jean L  wrote:


And you're saying that when you import this into a blank account, 
nothing shows up?


On 1/7/2023 10:52 AM, Tim Rohrer wrote:

Thanks, Jean.

Here is the entire file (attached and pasted). For testing, I was 
simply trying to get one transaction to work first.



DATA:OFXSGML
ENCODING:UTF-8




0
INFO

20230107105800
ENG






0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim









On Jan 7, 2023, at 12:41 PM, Jean L  wrote:


Can you post a small OFX file that's generated that way? I'll take a
quick look.

Jean

On 1/7/2023 10:18 AM, Tim Rohrer wrote:
I'm continuing my experimentation to migrate my Quicken for Mac 
data. I believe I'm on track for the investments, so I've switched 
back to regular accounts.


Originally, I was going to use the Quicken Mac 2007 Transfer File 
(QMTF aka QIF) but I started seeing some issues with how GnuCash 
handles splits, plus I'd lose tags and much of my notes.


Now I'm trying to usehttps://github.com/reubano/csv2ofx 
<https://github.com/reubano/csv2ofx> to generate OFX files from 
exported csv.


A dummy csv transaction:

Date,Payee/Security,Category,Amount,Account
1/1/2022,Tim,Income:Salary,500,Family Checking

Using csv2ox with a custom mapper, I get an ofx with guts of the 
transaction like this:





0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim





But nothing appears to import.

In my logs:

LibOFX INFO: libofx_proc_file(): File format not specified, 
autodetecting...

(Above message occurred on Line 40, Column 1)
LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open 
Financial eXchange (OFX or QFX))

(Above message occurred on Line 40, Column 1)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate SIGNONMSGSRSV1

(Above message occurred on Line 2, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate SONRS

(Above message occurred on Line 3, Column 3)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate BANKMSGSRSV1

(Above message occurred on Line 12, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported 
aggregate STMTTRNRS

(Above message occurred on Line 13, Column 3)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date 
part, but unable to parse time part of string 19700101. It is not 
in proper MMDDHHMMSS.XXX[gmt offset:tz name] format!

(Above message occurred on Line 27, Column 23)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date 
part, but unable to parse time part of string 20230107. It is not 
in proper MMDDHHMMSS.XXX[gmt offset:tz name] format!

(Above message occurred on Line 28, Column 21)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not 
finished


I do notice there is no category which could be a problem with my 
customer mapper, so I'll keep experimenting.


But, does anyone see what could be causing the error? Are the 
warnings of concern?


Tim
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnuc

Re: [GNC] OFX Requirements

2023-01-07 Thread Tim Rohrer

Correct. And the errors and warnings I pasted earlier are logged.Linux GnuCash 
4.11Build ID: 4.11+(2022-06-25)On Jan 7, 2023, at 12:53 PM, Jean L 
 wrote:And you're saying that when you import this into a
   blank account, nothing shows up?On 1/7/2023 10:52 AM, Tim Rohrer 
wrote:Thanks, Jean.Here is the entire file (attached and pasted). For testing,
 I was simply trying to get one transaction to work 
first.DATA:OFXSGMLENCODING:UTF-80INFO20230107105800ENG0INFOUSDb9fc6ca936ba09958d5076dd5ebfac69384d7d0b77b259606be9c29de2e05b45CHECKING1970010120230107CREDIT2022010100500.00743df964dc21309d6d8a7c0ca5eaa657TimOn
 Jan 7, 2023, at 12:41 PM, Jean L  wrote:Can you post a small OFX file that's generated that
   way? I'll take a quick look.JeanOn 1/7/2023 10:18 AM, Tim Rohrer 
wrote:I'm continuing my experimentation to migrate my
 Quicken for Mac data. I believe I'm on track for the
 investments, so I've switched back to regular
 accounts.Originally, I was going to use the Quicken Mac 2007
 Transfer File (QMTF aka QIF) but I started seeing some
 issues with how GnuCash handles splits, plus I'd lose
 tags and much of my notes.Now I'm trying to 
usehttps://github.com/reubano/csv2ofx <https://github.com/reubano/csv2ofx>
 to generate OFX files from exported csv.A dummy csv 
transaction:Date,Payee/Security,Category,Amount,Account1/1/2022,Tim,Income:Salary,500,Family
 CheckingUsing csv2ox with a custom mapper, I get an ofx
 with guts of the transaction like 
this:0INFOUSDb9fc6ca936ba09958d5076dd5ebfac69384d7d0b77b259606be9c29de2e05b45CHECKING1970010120230107CREDIT2022010100500.00743df964dc21309d6d8a7c0ca5eaa657TimBut
 nothing appears to import.In my logs:LibOFX INFO: libofx_proc_file(): File format not
 specified, autodetecting...(Above message occurred on Line 40, 
Column 1)LibOFX INFO: libofx_proc_file(): Detected file
 format: OFX (Open Financial eXchange (OFX or QFX))(Above 
message occurred on Line 40, Column 1)LibOFX INFO: Created OfxDummyContainer to 
hold
 unsupported aggregate SIGNONMSGSRSV1(Above message occurred on 
Line 2, Column 2)LibOFX INFO: Created OfxDummyContainer to hold
 unsupported aggregate SONRS(Above message occurred on Line 3, 
Column 3)LibOFX INFO: Created OfxDummyContainer to hold
 unsupported aggregate BANKMSGSRSV1(Above message occurred on 
Line 12, Column 2)LibOFX INFO: Created OfxDummyContainer to hold
 unsupported aggregate STMTTRNRS(Above message occurred on Line 
13, Column 3)LibOFX WARNING: ofxdate_to_time_t(): Successfully
 parsed date part, but unable to parse time part of
 string 19700101. It is not in proper
 MMDDHHMMSS.XXX[gmt offset:tz name] format!(Above message 
occurred on Line 27, Column 23)LibOFX WARNING: ofxdate_to_time_t(): Successfully
 parsed date part, but unable to parse time part of
 string 20230107. It is not in proper
 MMDDHHMMSS.XXX[gmt offset:tz name] format!(Above message 
occurred on Line 28, Column 21)LibOFX ERROR: OpenSP parser: otherError (misc 
parse
 error):/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS"
 which is not finishedI do notice there is no category which 
could be a
 problem with my customer mapper, so I'll keep
 experimenting.But, does anyone see what could be causing the
 error? Are the warnings of 
concern?Tim___gnucash-user mailing 
listgnucash-user@gnucash.orgTo update your subscription preferences or to
 
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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 
listgnucash-user@gnucash.orgTo update your subscription preferences or to
   
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Jean L
And you're saying that when you import this into a blank account, 
nothing shows up?


On 1/7/2023 10:52 AM, Tim Rohrer wrote:

Thanks, Jean.

Here is the entire file (attached and pasted). For testing, I was 
simply trying to get one transaction to work first.



DATA:OFXSGML
ENCODING:UTF-8




0
INFO

20230107105800
ENG






0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim









On Jan 7, 2023, at 12:41 PM, Jean L  wrote:


Can you post a small OFX file that's generated that way? I'll take a
quick look.

Jean

On 1/7/2023 10:18 AM, Tim Rohrer wrote:
I'm continuing my experimentation to migrate my Quicken for Mac 
data. I believe I'm on track for the investments, so I've switched 
back to regular accounts.


Originally, I was going to use the Quicken Mac 2007 Transfer File 
(QMTF aka QIF) but I started seeing some issues with how GnuCash 
handles splits, plus I'd lose tags and much of my notes.


Now I'm trying to usehttps://github.com/reubano/csv2ofx 
<https://github.com/reubano/csv2ofx> to generate OFX files from 
exported csv.


A dummy csv transaction:

Date,Payee/Security,Category,Amount,Account
1/1/2022,Tim,Income:Salary,500,Family Checking

Using csv2ox with a custom mapper, I get an ofx with guts of the 
transaction like this:





0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim





But nothing appears to import.

In my logs:

LibOFX INFO: libofx_proc_file(): File format not specified, 
autodetecting...

(Above message occurred on Line 40, Column 1)
LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open 
Financial eXchange (OFX or QFX))

(Above message occurred on Line 40, Column 1)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
SIGNONMSGSRSV1

(Above message occurred on Line 2, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
SONRS

(Above message occurred on Line 3, Column 3)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
BANKMSGSRSV1

(Above message occurred on Line 12, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
STMTTRNRS

(Above message occurred on Line 13, Column 3)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date part, 
but unable to parse time part of string 19700101. It is not in 
proper MMDDHHMMSS.XXX[gmt offset:tz name] format!

(Above message occurred on Line 27, Column 23)
LibOFX WARNING: ofxdate_to_time_t(): Successfully parsed date part, 
but unable to parse time part of string 20230107. It is not in 
proper MMDDHHMMSS.XXX[gmt offset:tz name] format!

(Above message occurred on Line 28, Column 21)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not finished

I do notice there is no category which could be a problem with my 
customer mapper, so I'll keep experimenting.


But, does anyone see what could be causing the error? Are the 
warnings of concern?


Tim
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Tim Rohrer

Thanks, Jean.Here is the entire file (attached and pasted). For testing, I was simply trying to get one transaction to work 
first.DATA:OFXSGMLENCODING:UTF-80INFO20230107105800ENG0INFOUSDb9fc6ca936ba09958d5076dd5ebfac69384d7d0b77b259606be9c29de2e05b45CHECKING1970010120230107CREDIT2022010100500.00743df964dc21309d6d8a7c0ca5eaa657TimOn
 Jan 7, 2023, at 12:41 PM, Jean L  wrote:Can you post a small OFX file that's generate
d that way? I'll take a quick look.JeanOn 1/7/2023 10:18 AM, Tim Rohrer wrote:I'm continuing my experimentation to migrate my Quicken for Mac data. I believe I'm on track for the investments, 
so I've switched back to regular accounts.Originally, I was going to use the Quicken Mac 2007 Transfer File (QMTF aka QIF) but I started seeing some issues with how GnuCash handles splits, plus 
I'd lose tags and much of my notes.Now I'm trying to usehttps://github.com/reubano/csv2ofx  <https://github.com/reubano/csv2ofx>  to generate OFX files from exported csv.A dummy csv 
transaction:Date,Payee/Security,Category,Amount,Account1/1/2022,Tim,Income:Salary,500,Family CheckingUsing csv2ox with a custom mapper, I get an ofx with guts of the transaction like 
this:0INFOUSDb9fc6ca936ba09958d5076dd5ebfac69384d7d0b77b259606be9c29de2e05b45CHECKIN
G1970010120230107CREDIT2022010100500.00743df964dc21309d6d8a7c0ca5eaa657TimBut
 nothing appears to import.In my logs:LibOFX INFO: libofx_proc_file(): File format not specified, autodetecting...(Above message occurred on Line 40, Column 1)LibOFX INFO: libofx_proc_file(): Detected file 
format: OFX (Open Financial eXchange (OFX or QFX))(Above message occurred on Line 40, Column 1)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate SIGNONMSGSRSV1(Above message occurred on Line 
2, Column 2)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate SONRS(Above message occurred on Line 3, Column 3)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
BANKMSGSRSV1(Above message occurred on Line 12, Column 2)LibOFX INFO: Created OfxDummyC
ontainer to hold unsupported aggregate STMTTRNRS(Above message occurred on Line 13, 
Column 3)LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable 
to parse time part of string 19700101. It is not in proper MMDDHHMMSS.XXX[gmt 
offset:tz name] format!(Above message occurred on Line 27, Column 23)LibOFX WARNING: 
ofxdate_to_time_t():  Successfully parsed date part, but unable to parse time part of 
string 20230107. It is not in proper MMDDHHMMSS.XXX[gmt offset:tz name] format!(Above 
message occurred on Line 28, Column 21)LibOFX ERROR: OpenSP parser: otherError (misc 
parse error):/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not 
finishedI do notice there is no category which could be a problem with my customer 
mapper, so I'll keep experimenting.But, does anyone see what could be causing the error? 
Are the warnings of 
concern?Tim___gnucash-user mailing 
listgnucash-user@gnucash.orgTo update your subsc
ription preferences or to 
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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 
listgnucash-user@gnucash.orgTo update your subscription preferences or to 
unsubscribe:https://lists.gnucash.org/mailman/listinfo/gnucash-user-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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] OFX Requirements

2023-01-07 Thread Jean L
Can you post a small OFX file that's generated that way? I'll take a 
quick look.


Jean

On 1/7/2023 10:18 AM, Tim Rohrer wrote:

I'm continuing my experimentation to migrate my Quicken for Mac data. I believe 
I'm on track for the investments, so I've switched back to regular accounts.

Originally, I was going to use the Quicken Mac 2007 Transfer File (QMTF aka 
QIF) but I started seeing some issues with how GnuCash handles splits, plus I'd 
lose tags and much of my notes.

Now I'm trying to usehttps://github.com/reubano/csv2ofx  
<https://github.com/reubano/csv2ofx>  to generate OFX files from exported csv.

A dummy csv transaction:

Date,Payee/Security,Category,Amount,Account
1/1/2022,Tim,Income:Salary,500,Family Checking

Using csv2ox with a custom mapper, I get an ofx with guts of the transaction 
like this:




0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim





But nothing appears to import.

In my logs:

LibOFX INFO: libofx_proc_file(): File format not specified, autodetecting...
(Above message occurred on Line 40, Column 1)
LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open Financial 
eXchange (OFX or QFX))
(Above message occurred on Line 40, Column 1)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
SIGNONMSGSRSV1
(Above message occurred on Line 2, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate SONRS
(Above message occurred on Line 3, Column 3)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
BANKMSGSRSV1
(Above message occurred on Line 12, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate STMTTRNRS
(Above message occurred on Line 13, Column 3)
LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable 
to parse time part of string 19700101. It is not in proper 
MMDDHHMMSS.XXX[gmt offset:tz name] format!
(Above message occurred on Line 27, Column 23)
LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable 
to parse time part of string 20230107. It is not in proper 
MMDDHHMMSS.XXX[gmt offset:tz name] format!
(Above message occurred on Line 28, Column 21)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not finished

I do notice there is no category which could be a problem with my customer 
mapper, so I'll keep experimenting.

But, does anyone see what could be causing the error? Are the warnings of 
concern?

Tim
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
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@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Variables in Scheduled transactions

2023-01-07 Thread Stan Brown (using GC 2.6.19)
Update -- 2.6.19 does prompt only once per variable, after all.

I thought it did, because, when the transaction fires, the UI for
prompting for an amount and accepting is pretty confusing (to me,
anyway). I entered the amount and clicked the OK button, but was
immediately prompted again for the same variable. By experimentation I
found that I have to press Enter after entering the amount, and _then_
click OK. (I'm using 2.6.19, so maybe the interface is a little clearer
in later versions.)

Now that I understand how the interface works, I have set up my mortgage
payment transaction as described below, and tested it successfully with
"Since Last Run".

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com

On 2023-01-05 08:38, Stan Brown wrote:
> 
> On 2023-01-05 02:17, Adrien Monteleone wrote:
>> Are you using GnuCash 4.13?
>>
>> I just tested this and I only get one prompt.
>>
>> Regards,
>> Adrien
>>
>> On 1/4/23 10:53 PM, Stan Brown wrote:
>>> Debit: Liabilities:Mortgage Principal  900-intamt
>>> Debit: Expenses:Mortgage Interest  intamt
>>> Credit:Assets:Bank Account 900.00
>>>
>>> I would like to be prompted for the interest due when the transaction
>>> fires, and then have GC compute the principal as 900.00 minus interest.
>>> But GC prompts me twice.
> 
> I'm sorry, I should have mentioned that I'm using 2.6.19. Sounds like
> this was fixed in a later version. Thanks for letting me know.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


[GNC] OFX Requirements

2023-01-07 Thread Tim Rohrer
I'm continuing my experimentation to migrate my Quicken for Mac data. I believe 
I'm on track for the investments, so I've switched back to regular accounts.

Originally, I was going to use the Quicken Mac 2007 Transfer File (QMTF aka 
QIF) but I started seeing some issues with how GnuCash handles splits, plus I'd 
lose tags and much of my notes.

Now I'm trying to use https://github.com/reubano/csv2ofx 
<https://github.com/reubano/csv2ofx> to generate OFX files from exported csv. 

A dummy csv transaction:

Date,Payee/Security,Category,Amount,Account
1/1/2022,Tim,Income:Salary,500,Family Checking

Using csv2ox with a custom mapper, I get an ofx with guts of the transaction 
like this:




0
INFO


USD

b9fc6ca936ba09958d5076dd5ebfac69
384d7d0b77b259606be9c29de2e05b45
CHECKING


19700101
20230107

CREDIT
2022010100
500.00
743df964dc21309d6d8a7c0ca5eaa657
Tim





But nothing appears to import. 

In my logs:

LibOFX INFO: libofx_proc_file(): File format not specified, autodetecting...
(Above message occurred on Line 40, Column 1)
LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open Financial 
eXchange (OFX or QFX))
(Above message occurred on Line 40, Column 1)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
SIGNONMSGSRSV1
(Above message occurred on Line 2, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate SONRS
(Above message occurred on Line 3, Column 3)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate 
BANKMSGSRSV1
(Above message occurred on Line 12, Column 2)
LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate STMTTRNRS
(Above message occurred on Line 13, Column 3)
LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable 
to parse time part of string 19700101. It is not in proper 
MMDDHHMMSS.XXX[gmt offset:tz name] format!
(Above message occurred on Line 27, Column 23)
LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable 
to parse time part of string 20230107. It is not in proper 
MMDDHHMMSS.XXX[gmt offset:tz name] format!
(Above message occurred on Line 28, Column 21)
LibOFX ERROR: OpenSP parser: otherError (misc parse error):
/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not finished

I do notice there is no category which could be a problem with my customer 
mapper, so I'll keep experimenting.

But, does anyone see what could be causing the error? Are the warnings of 
concern?

Tim
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] NEw user assistance

2023-01-07 Thread Karl
Thanks, John.

I am a self-directed investor, using an online broker. My structure would
be something like this:

Bank account ---> transfer funds to ---> online broker cash account (all in
CAD $) > all my investments


I then use my single online broker cash account to purchase my investments
(Canadian stocks, American stocks, etc.). If I purchase foreign stocks
(foreign to Canada), my broker automatically converts my CAD "broker cash
account" to USD to purchase the stock. There is no need for me to have two
broker cash accounts (one for CAD and one for USD) - all my investment cash
is kept in one account, in CAD.

Does that make sense? Hopefully I'm being clear.

So maybe I could set up my GnuCash Investment hierarchy something like:

-Online Broker Cash Account (all in CAD)

-USD Investments (parent account)

-AAPL stock

-AMZN stock

-etc

-CAD Investments (parent account)

-"individual CAD stocks"

-etc


Would that work?

Regards,

*Karl*


On Fri, 6 Jan 2023 at 23:22, john  wrote:

> GnuCash prioritizes direct prices over indirect ones, so if you have a
> single AAPL-CAD price in your price database and a bunch of AAPL-USD and
> USD-CAD ones the latter will be ignored when trying to price AAPL in CAD
> and you'll almost always get the single direct price.
>
> Two more important considerations: Every transaction in GnuCash has a
> single transaction currency and all prices created by that transaction are
> to/from the transaction currency. The transaction currency is determined by
> the account whose register has focus when you create it or by the From
> account when using the Transfer Dialog.
>
> If you're going to do multi-currency trading you want to enable Trading
> Accounts on the book. You do that on the first tab of File>Properties. One
> of the side effects of doing that is that the register shows amounts in the
> split account's currency instead of the Register account's currency. The
> following example will be written that way.
>
> To avoid creating that AAPL-CAD price you need to create a possibly fake
> USD cash account. If you purchase of US stocks involve an actual USD cash
> account then use that. Once the accounts are in place, do the following.
> For an e.g. to have numbers I'll assume a purchase of 100 shares of AAPL at
> today's closing price of 129.62 and 1 USD = 1.34429 CAD. 100 shares of
> AAPL, assuming a no-fee/no-commission brokerage and that the ask is the
> close, will cost USD 12,962.00, which is CAD 17,433.24. If you do this part
> from the CAD account you must use two transactions like so:
>
> 2023-01-06 Fund USD Cash for Purchase of 100 AAPL
> Assets:Investment:Cash-CAD CAD 17,433.24
> Assets:Investment:Cash-USD USD 12,962.00
>
> Now buy the stock in another transaction. Do this in either the AAPL or
> USD register to ensure that the transaction currency is USD!
> 2023-01-06 Buy AAPL 100
> Assets:Investment:Stocks:Stocks-USD:AAPL 100 129.62 12,1962.00
> Assets:Investment:Cash-USD 12,962.00
>
> If you start from the AAPL or Cash-USD account you can do it in a single
> transaction because the transaction currency will be USD, but you still
> need to do all four splits. Note that when you commit the transaction by
> pressing return or tabbing out of the blank split the Trading Accounts code
> will add 4 more Trading Account splits.
>
> A sell would be done the same way but in the other direction.
>
> Regards,
> John Ralls
>
>
> On Jan 6, 2023, at 1:45 PM, Karl  wrote:
>
> Hi there John,
>
> Thanks for the information. Very helpful! Perhaps I am setting up my
> foreign (USD) investment accounts all wrong. I'm trying to follow the
> instructions and examples in Chapters 9.5 and 9.6, but I can't
> reconcile the instructions with your explanation.
>
> So if I set-up the account structure as you described:
>
> Assets
> Investments
> Stocks
> Stocks-USD
> AAPL
>
>  ... when I go to make an initial purchase of AAPL shares/stock, do I
> enter the transaction in CAD or USD? For example, AAPL closed at $129.62
> USD today, so if I bought 10 stocks, should my entry be:
>
> DR AAPL stock  1,296.20 (USD)
>   CR Cash 1,296.20 (USD)
>
> or should it be:
>
> DR AALP stock  1,736.91 (CAD)
>   CR Cash  1,736.91 (CAD)
>
> ???
>
> CAD-USD was at $1.00 USD = $1.34 CAD.
>
>
> Ideally, when I run the "Advanced Portfolio" Report, I would like for what
> I'm seeing to be in CAD. Is this possible?
>
> Thanks again for your help. As you can probably tell, I'm terrible with
> computers, but not too bad with accounting! haha
>
> Regards,
>
> *Karl*
>
>
> On Fri, 6 Jan 2023 at 13:12, john  wrote:
>
>> That's a very long-running discussion with another Canadian CPA, see
>> https://bugs.gnucash.org/show_bug.cgi?id=797796
>> and https://bugs.gnucash.org/show_bug.cgi?id=798004.
>>
>> The simplest workaround is to set up an account structure that looks like
>> Assets
>> Investments
>> Stocks
>> Stocks-USD
>> AAPL
>>
>> As 

[GNC] OFX Requirements

2023-01-07 Thread Tim Rohrer

I'm continuing my experimentation to migrate my Quicken for Mac data. I believe I'm on track for the investments, so I've switched back to regular accounts.Originally, I was going to use the Quicken Mac 2007 Transfer File (QMTF aka QIF) but I started seeing some issues with how GnuCash handles splits, plus I'd lose tags and 
much of my notes.Now I'm trying to use https://github.com/reubano/csv2ofx to generate OFX files from exported csv. A dummy csv transaction:Date,Payee/Security,Category,Amount,Account1/1/2022,Tim,Income:Salary,500,Family CheckingUsing csv2ox with a custom mapper, I get an ofx with guts of the transaction like 
this:0INFOUSDb9fc6ca936ba09958d5076dd5ebfac69384d7d0b77b259606be9c29de2e05b45CHECKING1970010120230107CREDIT2022010100500.00743df964dc21309d6d8a7c0ca5eaa657TimBut
 nothing appears to import. In my logs:LibOFX INFO: libofx_proc_file(): File format not specified, autodetecting...(Above message occurred on Line 40, Column 1)LibOFX INFO: libofx_proc_file(): Detected file format: OFX (Open Financial eXchange (OFX or QFX))(Above message occurred on Line 40, Column 1)LibOFX INFO: Created 
OfxDummyContainer to hold unsupported aggregate SIGNONMSGSRSV1(Above message occurred on Line 2, Column 2)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate SONRS(Above message occurred on Line 3, Column 3)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate BANKMSGSRSV1(Above message occurred 
on Line 12, Column 2)LibOFX INFO: Created OfxDummyContainer to hold unsupported aggregate STMTTRNRS(Above message occurred on Line 13, Column 3)LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable to parse time part of string 19700101. It is not in proper MMDDHHMMSS.XXX[gmt offset:tz name] 
format!(Above message occurred on Line 27, Column 23)LibOFX WARNING: ofxdate_to_time_t():  Successfully parsed date part, but unable to parse time part of string 20230107. It is not in proper MMDDHHMMSS.XXX[gmt offset:tz name] format!(Above message occurred on Line 28, Column 21)LibOFX ERROR: OpenSP parser: otherError (misc 
parse error):/tmp/libofxtmpEkcf1m:37:11:E: end tag for "STMTRS" which is not finishedI do notice there is no category which could be a problem with my customer mapper, so I'll keep experimenting.But, does anyone see what could be causing the error? Are the warnings of concern?Tim
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Budget report fails in multiple currencies

2023-01-07 Thread ml enquirer
Hi Fred,

Thanks for the thought! I agree the change in value is 10,000. My point is,
basically, that I don't care about currency fluctuations in money already
spent when planning *next* year's budget.

But the 'problem' (which might just be that I need someone to explain what
a 'budget' is!) is (at least) two fold:
1) When I think 'budget' I think "planning how much I can spend in this
budget period". So I want the report to tell me that. If there are no
transactions in any child account, I don't expect a non-zero total in the
parent account. I certainly don't want a non-zero total that depends how
long I've been using gnucash. In the first year of using Gnucash, this
shows the total expense. In the 100th (hopefully!) year of using Gnucash,
this mainly shows the currency fluctuation of the history of my grocery
spending in years 0-99! These are totally different things, at least for
the typical use of an expense account like 'groceries'.
2) The budget report and the budget view seem to show the totals
aggregating in different ways. I would expect correspondence.

When you think "budgetting this year's groceries", why would you care about
having to plan for the currency fluctuation in what has already been spent,
and which is no longer available to spend, and which has no impact on what
can be spent this year? Is there another report that you'd recommend that I
use?

Let me be gently provocative: I think my described use-case is more widely
relevant, at least for expense accounts if not for asset accounts ;) But as
I keep on saying, I'm very ignorant of even basic accountancy techniques,
so feel free to (gently) teach me!

D

On Sat, Jan 7, 2023 at 6:08 PM Fred Bone  wrote:

> On 07 January 2023 at 10:21, ml enquirer said:
>
> > Just to add that I was wrong that this could be solved by making budgets
> > with a single period. I *think* this problem arises for any
> multi-currency
> > sub-accounts and becomes visible when you have a book which has been
> > running for many years. In that circumstance, the 'actual' column is only
> > incrementally affected by spends during the actual reporting period
> (which
> > are small compared to the cumulative spending over the years).
> >
> > Imagine a case where there is *no* spend on any sub-account in a
> reporting
> > period, but the years prior total 1,000,000 EUR and 1,000,000 GBP.
> Imagine
> > the exchange rate is 1 EUR to GBP at the start of this new 'empty' period
> > and 1 EUR to 1.01 GBP at the end. 1) The computed total at the start will
> > be 1,000,000 EUR + 1,000,000 GBP = 2,000,000 GBP. 2) The computed total
> at
> > the end will be 1,000,000 EUR + 1,000,000 GBP = 2,010,000 GBP and the
> > reported "Actual" spend will be 10,000 GBP despite nothing having been
> > spent.
>
> The change in value is indeed 10,000. What's the problem?
>
>
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Dr. David Kirkby
On Sat, 7 Jan 2023 at 14:37, Maf. King  wrote:

>
> Is the Effective Legal Tax date 6th or 19th?  Enter it to that date.  The
> reconcilliation will not be affected either way.
>
> Maf.


Certainly not the 19th, but probably not the 6th either. It was for postage
and a pickup fee. I must have cancelled the pickup and rebooked it for a
later date. So arguably it is an unknown date between the two.  

The amount is only £0.60 (< $1 USD), and nowhere near the end of the
accounting period, so I don’t think anyone is going to be too bothered
about the accuracy of the information.

I think setting it the 6th is probably best, as that’s consistent with more
than 90% of the transactions. I was concerned that it might cause problems
with reconciliation, in which case I would certainly not want to risk
problems with that.
-- 
Dr. David Kirkby,
Kirkby Microwave Ltd,
drkir...@kirkbymicrowave.co.uk
https://www.kirkbymicrowave.co.uk/
Telephone 01621-680100./ +44 1621 680100

Registered in England & Wales, company number 08914892.
Registered office:
Stokes Hall Lodge, Burnham Rd, Althorne, Chelmsford, Essex, CM3 6DT, United
Kingdom
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Budget report fails in multiple currencies

2023-01-07 Thread Fred Bone
On 07 January 2023 at 10:21, ml enquirer said:

> Just to add that I was wrong that this could be solved by making budgets
> with a single period. I *think* this problem arises for any multi-currency
> sub-accounts and becomes visible when you have a book which has been
> running for many years. In that circumstance, the 'actual' column is only
> incrementally affected by spends during the actual reporting period (which
> are small compared to the cumulative spending over the years).
> 
> Imagine a case where there is *no* spend on any sub-account in a reporting
> period, but the years prior total 1,000,000 EUR and 1,000,000 GBP. Imagine
> the exchange rate is 1 EUR to GBP at the start of this new 'empty' period
> and 1 EUR to 1.01 GBP at the end. 1) The computed total at the start will
> be 1,000,000 EUR + 1,000,000 GBP = 2,000,000 GBP. 2) The computed total at
> the end will be 1,000,000 EUR + 1,000,000 GBP = 2,010,000 GBP and the
> reported "Actual" spend will be 10,000 GBP despite nothing having been
> spent.

The change in value is indeed 10,000. What's the problem?


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Maf. King
On Saturday, 7 January 2023 14:21:21 GMT Dr. David Kirkby wrote:
> I'm inputting my 2022 accounts, and have reconciled up to 10/04/2022
> (DD/MM/). Now I just found a refund, dated 06/04/2022, but does not
> appear in the bank account until 19/04/2022. Is it safe to create a credit
> note, dated 06/04/2022, then reconcile up to 19/04/2022 at a later date? Or
> should I date it 19/04/2022, and reconcile up to that at a later date?
> 

Is the Effective Legal Tax date 6th or 19th?  Enter it to that date.  The 
reconcilliation will not be affected either way.

Maf.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Is a screwed-up style sheet hiding somewhere?

2023-01-07 Thread Dr. David Kirkby
On Fri, 6 Jan 2023 at 23:18, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Fair enough.
>
> I see you managed to clear it up with a registry edit.
>
> I did manage to get a similar looking invoice to yours by default
> though. That was via Reports > Business > Fancy Invoice.
>
> The other options of Easy, Printable, & Tax Invoice are more sane looking.


It’s difficult for me to comprehend why that fancy template in that form
should exist at all. I don’t think anyone could consider it sane. I
reported it a bug

https://bugs.gnucash.org/show_bug.cgi?id=798717

and see it has been closed with a note that it will be fixed in the next
release.

I thought that “Reset Defaults” in that part of the software would have
reset the default invoice to be the default one.

>
>
> You can change the 'default' Invoice template to Fancy (not that you'd
> want to now) via Preferences > Business > Report for printing.


Thank you. I had created an invoice with my company logo, which I would
have liked to use as a default. I will recreate that now, tweak it a bit as
I am not 100% satisfied, then save that as a default. (I was a bit
surprised that setting the width of the banner to 1” was about optimal. The
manual says one will have to experiment, but suggests 6” x 1” to be
reasonable. Clearly 6” wide is very different to 1” wide)


I'd bet
> you had it set for the Fancy template before your re-install and regedit
> attempt.


I don’t know for certain, but I expect that you are right. The description
of the layout clearly shows that the information is duplicated. Anyway, it
will be fixed in the next release.

-
> As a side note here, maybe take from a clean install, a copy of the
> settings location folders as a backup to do a quick restore. For the
> registry entries, I think you can export selected folders/keys as a
> subset that can be 're-imported' if needed rather than have to manually
> edit individual keys. (This is how installations work behind the scenes)
> I don't recall all of those steps as I haven't regularly used Windows in
> years, but I know it can be done.


Thank you for the suggestion. I would much prefer to be using a Linux
computer myself. Unfortunately the Linux computer is in my lab, which is
detached from the house. In order to use that computer I would need to run
the air conditioning to keep the room temperature comfortable, then use a
power hungry computer to use some software that uses very little CPU power
or memory. I think I should invest in a more general purpose computer. It
is very rare for me to need several hundred of GB of RAM.



Regards,
> Adrien


Dave
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


[GNC] Will adding a transaction dated earlier than the last reconciliation cause a problem?

2023-01-07 Thread Dr. David Kirkby
I'm inputting my 2022 accounts, and have reconciled up to 10/04/2022
(DD/MM/). Now I just found a refund, dated 06/04/2022, but does not
appear in the bank account until 19/04/2022. Is it safe to create a credit
note, dated 06/04/2022, then reconcile up to 19/04/2022 at a later date? Or
should I date it 19/04/2022, and reconcile up to that at a later date?

Dr David Kirkby Ph.D
Email: drkir...@kirkbymicrowave.co.uk Web:
https://www.kirkbymicrowave.co.uk/
Kirkby Microwave Ltd (Tel 01621-680100 / +44 1621-680100)
Stokes Hall Lodge, Burnham Rd, Chelmsford, Essex, CM3 6DT.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Where do I set the "Accounting Period" for reports?

2023-01-07 Thread Stan Brown (using GC 2.6.19)
> On 1/6/23 2:41 PM, Stan Brown wrote:
>> I don't think there's a global setting for time period in reports. It
>> would be nice if there were -- why not enter an enhancement request?


On 2023-01-06 13:13, Adrien Monteleone wrote:
> There already is such a preference. It is the very first preference on
> the first tab.
>
> Most reports (certainly annual ones) default to 'beginning of
accounting period' and 'end of accounting period'.


Ah, right. The preference is labelled "Accounting period" and when I set
up all my preferences I didn't connect that in my mind with reports. But
I agree that reports seem to default to "accounting period", so the
preference you mention is a de facto global setting.

Or at least it would be, if I hadn't set all my reports to last year or
last month or this year or this month. :-) I'll go and change the
reports' options (back) to "accounting period" when I get a chance.

Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Where do I set the "Accounting Period" for reports?

2023-01-07 Thread Chris Green
On Fri, Jan 06, 2023 at 12:41:22PM -0800, Stan Brown wrote:
> 
> On 2023-01-06 11:35, Chris Green wrote:
> > On Fri, Jan 06, 2023 at 07:17:46PM +1000, David H wrote:
> >> Chris,
> >>
> >> Did you run a report then click on Options / General Tab - the reports I
> >> run allow you to set the period for each report?
> >>
> > That's absolutely the last thing I want to do, I want the same period
> > for every report after entering it just once!
> 
> I don't think there's a global setting for time period in reports. It
> would be nice if there were -- why not enter an enhancement request?
> 
> I know it's a pain to set up a time period for each individual report,
> but you only have to do it once (per report). And if you are smart about
> it, you'll use settings like "start of previous month" or "end of
> accounting period".
> 
> When you click "Save Report Configuration As", be sure to use some
> reasonable naming convention, one that makes sense to you.
> 
I really don't want or need to save reports, it's just one more bit of
configuration that I'd need to keep track of.  I want things to be
configured in as few places as possible.

A saved report is of little use the next year (wrong headings often).
What I want is to set things up so that whenever I click on (for
example) Transaction Report I just get that and not have to jump
through several hoops to actually get any meaningful output.

-- 
Chris Green
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


Re: [GNC] Budget report fails in multiple currencies

2023-01-07 Thread ml enquirer
Just to add that I was wrong that this could be solved by making budgets
with a single period. I *think* this problem arises for any multi-currency
sub-accounts and becomes visible when you have a book which has been
running for many years. In that circumstance, the 'actual' column is only
incrementally affected by spends during the actual reporting period (which
are small compared to the cumulative spending over the years).

Imagine a case where there is *no* spend on any sub-account in a reporting
period, but the years prior total 1,000,000 EUR and 1,000,000 GBP. Imagine
the exchange rate is 1 EUR to GBP at the start of this new 'empty' period
and 1 EUR to 1.01 GBP at the end.
1) The computed total at the start will be 1,000,000 EUR + 1,000,000 GBP =
2,000,000 GBP.
2) The computed total at the end will be 1,000,000 EUR + 1,000,000 GBP =
2,010,000 GBP
and the reported "Actual" spend will be 10,000 GBP despite nothing having
been spent.

This reporting bug gets worse the longer gnucash is used.

Thanks,
D

On Sat, Jan 7, 2023 at 9:52 AM ml enquirer  wrote:

> Hi Adrien,
>
> Thanks for the mental bandwidth on this. I don't like replying inline, but
> I'm going to grit my teeth and do it here - forgive me!
>
> Cheers,
> D
>
> On Sat, Jan 7, 2023 at 12:47 AM Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
>
>> Christopher Lamm had been working on various aspects of the Budget
>> Report not long ago. He may be able to squeeze in a look at this. He'll
>> likely be the one to see your bug report and maybe shed light on the
>> math logic.
>>
> Great: https://bugs.gnucash.org/show_bug.cgi?id=798716
>
>
>> If I can find some time this weekend I'll test as well. I normally don't
>> budget with multiple currencies, but I do use the Budget feature and
>> report. (looking at your screenshot, I've never done a multi-year
>> budget, so that will be interesting. I'll test too with a single year.)
>>
> The pragmatic way around this is to only use budget reports with a single
> budget period when multiple currencies are used in sub-accounts. Things
> then work because the starting "actual" value is always zero.
>
>
>> Concerning the 'roll-up', if you leave the parent blank, it should work.
>> (at least it does with a single currency) *But*, you can also put in a
>> different value manually for the parent. I'm not sure if that is in play
>> here or not. The parent has to be entirely blank, not just a "0" or "0.00"
>>
>> *note, this is for the Budget itself, your screenshot showed the report
>> result, but does the parent roll-up not work on the budget tab either?
>>
> Interesting. Here the budget and the budget report behave differently. The
> roll-up *does* acknowledge the change in FX rate, but behaves as I'd expect
> (see screenshot attached)
>
>>
>> With respect to the 'past-period memory', it could be buggy, but I'd be
>> inclined to first look really carefully at my report options, *and* the
>> budget period setup. (Edit > Budget Options, or Options toolbar button
>> once a budget is already open - different from Options button on the
>> report tab) I once made an odd mess here myself that produced strange
>> numbers that didn't make sense.
>>
>> Specifically with the Report Options, the General tab can make things
>> messy with respect to custom ranges, and Accounts > Account Depth can
>> produce odd results if not sufficiently deep, or if flattened.
>>
> Depth was enough to capture all sub-accounts and ranges were sensible (and
> covered all transactions). I admit it is possible to screw this up as you
> warn - and perhaps I still have - but I think I've picked it simply
>
>>
>> Additionally, did you simply manually enter all budget values, or did
>> you perhaps use the Estimate feature?
>>
> Manually entered.
>
>>
>> Finally, does this book have Trading Accounts enabled by chance? I think
>> I understood from your first post that you aren't using them yet. (mine
>> does, so I'll test with and without to see if there is difference)
>>
> No trading accounts.
>
>>
>> -
>> I've been in the habit of hazarding guesses lately, so here's one for
>> this topic:
>>
>> Since the Budget Report does not have an option for commodity price
>> source like other reports cognizant of other currencies, I'll
>> hypothesize that budgets simply aren't (yet) capable of properly working
>> with more than one, or any currency other than the book currency.
>>
>> Regards,
>> Adrien
>>
>> On 1/6/23 4:48 PM, ml enquirer wrote:
>> > Dear all,
>> >
>> > I've done some digging, and Gnucash totals seem to be wrongly reported
>> for
>> > budget reports with multi-currency sub-accounts. But I'm not an
>> accountancy
>> > expert at all, so perhaps someone can explain the accounting logic
>> behind
>> > it? Perhaps a report that can imply 1+1=3 should have a warning note?
>> > Should we be ensuring that accounts add up across budget periods, or
>> down
>> > hierarchies within budget periods? Gnucash is doing the former, but it's
>> > 

Re: [GNC] Register column sizing

2023-01-07 Thread David H
Yes, working right to left is the way to do it, generally it works like a
charm once you get used to it, I find it just as easy sometimes to left
click on the column divider and move it left or right as necessary.
Sometimes I still have to click on the right hand border of the autosized
Description column and pull it leftwards for a cm or 2 and let it go to get
it to resize tho :-)

I find myself generally using Gnucash on the left side of my screen with a
browser window open to my bank/s on the right with both taking up the full
screen trying to make sure everything has been entered and reconciles with
Gnucash.  Personally I'd really like the text columns like Description,
Transfer, Notes (are there others ?) to automatically all slim down
proportionately when I click on the right Gnucash window border and shrink
the window width and similarly expand proportionately when I expand the
window again :-)  What happens at present is that the Description column
shrinks down but I seem to just end up losing all or most of the
reconciliation and amount columns and then I also start losing most of the
Transfer column as well. So then I have to manually shrink the column width
of the Transfer column to get the amounts showing again.

Not sure what you can do about users shrinking down and losing the
Reconciliation column etc as per MAF's earlier reply.  If that happens to
me I can usually manage with a bit of trial and error to click on the very
slightly thicker column divider where the Reconciliation column was and
expand it again.  Maybe a button on the toolbar to "Unhide Columns" that
are zero width, then again perhaps MAF's idea of a minimum column width
would work and be easier to implement.

I wasn't sure what John's comment about the hidden price column was all
about until I managed to expand a hidden "Rate" column on the right of my
Registers - I think this was mentioned a year or two back ?

Regards David H.


On Sat, 7 Jan 2023 at 13:16, Fred Tydeman  wrote:

> I find that doing a double left click on each column header,
> going from right to left works just fine.
>
> On Fri, Jan 6, 2023 at 7:11 PM peterb  wrote:
>
> > I have been using Gnucash for many years and I still never know exactly
> > what's going to happen when I try to resize a column. It is 120%
> > infuriating - at least to me! - so I'm in favor of trying to make the
> > behavior more sensible.
> >
> > It feels fundamentally weird to me to privilege the description column
> that
> > way, because it means I constantly end up in situations where space is
> > being added to the description column, which in the common case has
> plenty
> > of room, and in the meantime my debit and credit columns are cutting off
> > half the numbers in them.
> >
> > -Peter
> >
> > On Thu, Jan 5, 2023 at 10:42 PM john  wrote:
> >
> > > Users,
> > >
> > > There have been occasional complaints for many years about column width
> > > sizing. See for e.g. https://bugs.gnucash.org/show_bug.cgi?id=563588.
> > > Most users seem to eventually get used to it, but I wonder if anybody
> > > really likes it.
> > >
> > > The problem boils down to the auto-sizing behavior of the Description
> > > column, which causes that column to grow or shrink when you adjust the
> > > window's width, and to make a horizontal scrollbar appear when you
> widen
> > > another column. Occasionally someone will complain about the normally
> > > hidden price column because it's possible to catch its handle and widen
> > it
> > > when you mean to widen the balance column.
> > >
> > > It would be really easy to turn off autosizing on the Description field
> > > and only a little work to figure out another way to handle the price
> and
> > > ditch that column. Would anyone miss it?
> > >
> > > Regards,
> > > John Ralls
> > >
> > > ___
> > > gnucash-user mailing list
> > > gnucash-user@gnucash.org
> > > To update your subscription preferences or to unsubscribe:
> > > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > > -
> > > 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@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > 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@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> 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@gnucash.org
To update 

Re: [GNC] Budget report fails in multiple currencies

2023-01-07 Thread ml enquirer
Hi Adrien,

Thanks for the mental bandwidth on this. I don't like replying inline, but
I'm going to grit my teeth and do it here - forgive me!

Cheers,
D

On Sat, Jan 7, 2023 at 12:47 AM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Christopher Lamm had been working on various aspects of the Budget
> Report not long ago. He may be able to squeeze in a look at this. He'll
> likely be the one to see your bug report and maybe shed light on the
> math logic.
>
Great: https://bugs.gnucash.org/show_bug.cgi?id=798716


> If I can find some time this weekend I'll test as well. I normally don't
> budget with multiple currencies, but I do use the Budget feature and
> report. (looking at your screenshot, I've never done a multi-year
> budget, so that will be interesting. I'll test too with a single year.)
>
The pragmatic way around this is to only use budget reports with a single
budget period when multiple currencies are used in sub-accounts. Things
then work because the starting "actual" value is always zero.


> Concerning the 'roll-up', if you leave the parent blank, it should work.
> (at least it does with a single currency) *But*, you can also put in a
> different value manually for the parent. I'm not sure if that is in play
> here or not. The parent has to be entirely blank, not just a "0" or "0.00"
>
> *note, this is for the Budget itself, your screenshot showed the report
> result, but does the parent roll-up not work on the budget tab either?
>
Interesting. Here the budget and the budget report behave differently. The
roll-up *does* acknowledge the change in FX rate, but behaves as I'd expect
(see screenshot attached)

>
> With respect to the 'past-period memory', it could be buggy, but I'd be
> inclined to first look really carefully at my report options, *and* the
> budget period setup. (Edit > Budget Options, or Options toolbar button
> once a budget is already open - different from Options button on the
> report tab) I once made an odd mess here myself that produced strange
> numbers that didn't make sense.
>
> Specifically with the Report Options, the General tab can make things
> messy with respect to custom ranges, and Accounts > Account Depth can
> produce odd results if not sufficiently deep, or if flattened.
>
Depth was enough to capture all sub-accounts and ranges were sensible (and
covered all transactions). I admit it is possible to screw this up as you
warn - and perhaps I still have - but I think I've picked it simply

>
> Additionally, did you simply manually enter all budget values, or did
> you perhaps use the Estimate feature?
>
Manually entered.

>
> Finally, does this book have Trading Accounts enabled by chance? I think
> I understood from your first post that you aren't using them yet. (mine
> does, so I'll test with and without to see if there is difference)
>
No trading accounts.

>
> -
> I've been in the habit of hazarding guesses lately, so here's one for
> this topic:
>
> Since the Budget Report does not have an option for commodity price
> source like other reports cognizant of other currencies, I'll
> hypothesize that budgets simply aren't (yet) capable of properly working
> with more than one, or any currency other than the book currency.
>
> Regards,
> Adrien
>
> On 1/6/23 4:48 PM, ml enquirer wrote:
> > Dear all,
> >
> > I've done some digging, and Gnucash totals seem to be wrongly reported
> for
> > budget reports with multi-currency sub-accounts. But I'm not an
> accountancy
> > expert at all, so perhaps someone can explain the accounting logic behind
> > it? Perhaps a report that can imply 1+1=3 should have a warning note?
> > Should we be ensuring that accounts add up across budget periods, or down
> > hierarchies within budget periods? Gnucash is doing the former, but it's
> > confusing since the display can imply only the latter is in action.
> >
> > I built a local copy of gnucash and tracked the calls through budget.scm
> > back to the totalling and currency-conversion that happens in Account.cpp
> > and I see where the confusion arises. There is memory of previous budget
> > periods built into the reported totals under each asset class (see the
> > detail below and the picture attached).
> >
> > Isn't it a bit counter-intuitive that the budget reports for 'parent'
> > account values in a given budget period, don't need to add up to the sum
> of
> > the 'child' account values when converted by the exchange rate relevant
> for
> > that budget period? I give lots of detail below, where it's clear the
> > report is not "buggy", but it is borderline misleading, particularly
> given
> > that the report can be restricted to a single budget period within which
> it
> > appears to say that 30,000 GBP is the sum of 10,000 GBP and 10,000 EUR,
> > when the exchange rate is 1GBP = 1EUR. 1+1=3?
> >
> > Would love some expert input. Maybe I should report this as a bug and let
> > someone set me right there? :)
> >
> > Cheers,
> > D
> >
> > PS: Here's the 

Re: [GNC] Request for Automatic Reconciliation Function

2023-01-07 Thread David T. via gnucash-user
Bite Gao,

Jim mentions the import matcher, and I reiterate here to emphasize that GnuCash 
provides most of what you're asking, but places it in the import process, 
rather than in reconciliation. A user can match incoming entries to existing 
ones. They can also set the reconcile flag to "C" for imported transactions, 
which will automatically check those entries on the next reconciliation. These 
are both key parts of your proposal. 

And the problems that others raised continue to undermine the idea. 

⁣David T. ​

On Jan 7, 2023, 4:35 AM, at 4:35 AM, Jim DeLaHunt  wrote:
>Bite Gao:
>
>Thank you for continuing this conversation. I am glad to have your
>ideas 
>in this discussion.
>
>While I think I understand what feature you are asking for, I do see 
>some difficulties with it. For example, you say:
>
>On 2023-01-06 17:22, Bite Gao wrote:
>> …For each split record in the GnuCash file, the program scan for its 
>> counterpart in the bank statement.… Personally, I do not found that 
>> how computer program could make mistake in this process.…
>
>The obvious difficulty is that for a single transaction, the text in
>the 
>GnuCash file is probably different than the text in its counterpart in 
>the bank statement. For example, suppose I have a weekly purchase where
>
>I enter the description as "SPUD, Vancouver BC" and the date as January
>
>5, but the bank statement may say "Small Potatoes Delivery * Paypal"
>and 
>the date as January 6.  It is difficult — not impossible, but difficult
>
>— for GnuCash to see that these two transactions are counterparts.
>Their 
>description text and their dates differ.
>
>It turns out that GnuCash's Import Matcher can successfully recognise 
>the link between these two.  But it often makes mistakes in this
>process.
>
>Best regards,
>     —Jim DeLaHunt
>
>
>On 2023-01-06 17:22, Bite Gao wrote:
>> GnuCash Developers and Maintainers:
>>   Hello! While you pinpoint out the possibility of a mistake in 
>> automated process, it did not eliminate the meaning of the automatic 
>> reconciliation.
>>   What an automatic reconciliation does is: the program concatenates 
>> the transaction's date, check number and the transaction amount from 
>> both the bank statement and the GnuCash file. For each split record
>in 
>> the GnuCash file, the program scan for its counterpart in the bank 
>> statement. And when the counterpart is found, the program marks the 
>> split as reconciled.
>>   Personally, I do not found that how computer program could make 
>> mistake in this process. If you believe that the computer could have 
>> that happen, I would like to learn the detail about it.
>>
>>   Yours,
>>
>>    Bite Gao
>> Jan 7th, 2021
>>
>> On 2023/1/6 20:57, Adrien Monteleone wrote:
>>
>>> I understand your explanation, but if you aren't checking and 
>>> verifying every transaction, how do you ever discover when the 
>>> automated process makes a mistake?
>>>
>>> Reconciliation was invented long before computers, but I appreciate 
>>> that the process demands one to slow down, take your time, and 
>>> methodically verify the information.
>>>
>>> Think of it as proof-reading - the hard way. (I learned in school to
>
>>> read stuff backwards when proofing!)
>>>
>>> That is a pretty good analogy too:
>>>
>>> If you've ever used auto-correct with auto-checking for spelling and
>
>>> grammar, or auto-suggestion or auto-completion for entire words and 
>>> have seen the embarrassment and/or nightmare that can produce when 
>>> the computer 'gets it wrong', would you want something like that for
>
>>> your financial records?
>>>
>>> Regards,
>>> Adrien
>>>
>>> On 1/5/23 7:50 PM, Bite Gao wrote:
 GnuCash Developers and Maintainers:
    Hello! While you have mentioned the requirement of human 
 intervene in the reconciliation process, I do not see it
>contradicts 
 with the presence of automatically reconciliation system.
    In a reconcile process, the accountant check the record in the 
 account book with the record in the bank statement (or statement 
 from other institution). He (or she) may found out that two record 
 are identical, or he (or she) may found that some record are not 
 identical. Only the latter requires human notice, since there its
>no 
 point wasting time on reconciled accounting transactions. An 
 automatic reconciliation system can load the digital statement from
>
 the institution, compares the statement with the transaction in the
>
 accounting book, and pinpoints the discrepancies out. Then human 
 accountant could step in and perform manual operations, such as 
 checking other vouchers, contact with banks, etc. In the situation 
 of single user, the automatic reconcile system have no reason to 
 block manu
 al reconciliation.
    Besides, when I means "human err", I means that the accountant 
 overlook an discrepancy and regards it as identical. People do not 
 spend too much time on