Re: [GNC-dev] Semi-Floating decimal in stock shares

[Bob Gustafson]

Sometimes it is nice to see all of the decimal points aligned when 
viewing a column of numbers. Some investments come in thousandths of a 
share. Not trimming is not a bug.


On 8/20/19 1:01 PM, David G. Pickett via gnucash-devel wrote:

Trivial bug/suggestion: While I never see stock balances or shares x.xx0, I do 
see x.x0 and x.00 on stock transaction account pages!  If it is proper to 
remove one trailing fractional zero from a three decimal to the right of the 
point stock shares or balance column number on stock transaction account pages, 
why not remove 2 trailing zeros, or even 3?  Or keep all three places and have 
the decimal points in line?  Or make it an option to trim all or none?  
Trimming just one zero when there were 2 or 3 is a bug, at any rate.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] End of 'X' date on 3.4-50 (maint)

[Bob Gustafson]

Whenever I can, I use/convertTo the format 2019-02-02 (unfortunate that 
today is the 2nd of February. Things are less ambiguous near the end of 
months). This format is more native to SQL databases and also will sort 
reasonably when used in flat file names.


I think the US Govt issues passports with expiration dates in the last 
half of the month - just to cut down the confusion. (This may have 
changed though..)


Decades ago I searched for 24hr watches - smart phones have eliminated 
that need.


Have fun - Bob G

On 2/2/19 6:19 AM, Herbert Thoma wrote:

Am 02.02.19 um 00:27 schrieb Wm via gnucash-devel:

On 30/01/2019 01:54, Stephen M. Butler wrote:

I compiled origin/maint (gnucash 3.4-50) and noticed that the end of
accounting period was at 12/31/2020 while the start of accounting 
period

is at 1/1/2019.

Checked:

* Today:  1/29/2019


what the fuck do you expect if you are using american dates


Hmm, I would think that the problem is not the backwards US date
format. I would rather think that if the start of accounting
period is 1/1/2019, then the end should be 12/31/20*19* instead
of 12/31/20*20*.


this is not news.


This seems to me like a bug.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Import PDF to GnuCash

[Bob Gustafson]

Take a look at Tesseract

https://github.com/tesseract-ocr/tesseract


On 07/26/2018 02:56 PM, deltatango wrote:


Hello,

Very interested in the possibility of importing PDF statements into GnuCash.

I know Quickbooks now has this functionality.

I searched online and found a few clunky possibilities that would convert
the data into excel which can then be converted to csv and then imported
into GnuCash.

I was envisioning a system where you select a PDF statement to be imported.

The program then asks you to select the area of the statement which contains
the transactions, much like a photoshop selection. (And perhaps you could
save templates of selections for different statements).

Then some kind of OCR scanning reads the columns and data and convert it to
columns/rows.

Is this in the realm of possibility for some future release?

It is so common now that exporting csv or qfx ,etc files from your bank only
go so far back and you have to download PDFs instead...

I dream, I hope...

But in vain I wish not...



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: transaction.scm date subtotal options - calling wizards ...

[Bob Gustafson]

Hi Christopher

I use a program with a massive pattern recognition phase that sorts 
MT940 bank transaction records into categories. It has evolved over a 
decade to help prepare US taxes for German real estate properties.


The data is entered by other people. You cannot believe how many ways 
there are to spell the name of one electrical contractor - with umlauts, 
with 'UE' instead of umlaut, upper case, lower case, misspelled.. Each 
has been categorized correctly with an additional pattern. Also, over 
the decade, the bank has evolved their export data format from csv to 
mt940. Also the character set has changed - finally settling on UTF-8 a 
few years ago.


Hopefully your report desires are less ambitious. My program is written 
in Ruby and accesses a postgresql database. If I were to rewrite it 
today, it would be in Nim (http://nim-lang.org/)


I use GNUCASH, but just as a viewer of input data and some intermediate 
results.


Best regards - BobG

On 09/22/2017 10:41 AM, Christopher Lam wrote:

Hi John,



The origin of this project comes from my wish to produce report... "how
much did I spend on various categories, in this quarter?"


Source account=Asset:Bank.

Prime-sortkey=date

Prime-subtotal=quarterly

Sec-sortkey=other-accname

Sec-subtotal=true



2016Q1

Expense:Groceries

01/01/16 – Allmart $200

01/02/16 – Qmart $300

01/03/16 – Nomart $300

*Subtotal Expense:Groceries $800*

Expense:Petrol

15/01/16 – Coral $300

15/02/16 – BQ $250

* Subtotal Expense:Petrol $550*

* Subtotal 2016Q1 = $1350*



However the current query mechanism means that the dates will be split up,
because, although they belong to the same quarter, they have different
dates.

qof-query mechanism cannot sort by quarter... can only sort by date.


I attach 2 screenshots to illustrate and the sample test file. This is my
amended transaction.scm and the original/custom sorter can be chosen in the
checkbox.


C

On 22 September 2017 at 23:33, Christopher Lam 
wrote:


Hi John,



The origin of this project comes from my wish to produce report.

Source account=Asset:Bank. Prime-sortkey=date (subtotal quarterly) and
sec-sortkey=other-accname (subtotal=true).



2016Q1

Expense:Groceries

01/01/16 – Allmart $200

01/02/16 – Qmart $300

01/03/16 – Nomart $300

*Subtotal Expense:Groceries $800*

Expense:Petrol

15/01/16 – Coral $300

15/02/16 – BQ $250

* Subtotal Expense:Petrol $550*

* Subtotal 2016Q1 = $1350*



However the current query mechanism means that the dates will be split up,
because they’



Sent from Mail  for
Windows 10



*From: *John Ralls 
*Sent: *Friday, 22 September 2017 10:40 PM
*To: *Christopher Lam 
*Cc: *gnucash-de...@lists.gnucash.org
*Subject: *Re: transaction.scm date subtotal options - calling wizards ...







On Sep 22, 2017, at 5:48 AM, Christopher Lam 
wrote:



Hi devs,

While working on transaction.scm (again) to fix a sorting/grouping bug[1],
I came across some inconsistencies:

1. if I choose sortkey "date" "exact-time" -- they do the exact same thing,
but otherwise work well

2. if I choose sortkey "reconciled date" -- it does what it says, however
*the date-subtotal selector is not used at all.*

3. if I choose sortkey "register order"
(a) first, I'm not entirely sure what exactly this mean - *does it mean,
sort by EntryDate *(accessible by xaccTransGetDateEntered
)

(b) second, it allows date-subtotal selection, which to me is puzzling, but
could be acceptable if we're sorting by EntryDate

My conclusion from above would be that the original date-sorting-types has
a typo, it was (define date-sorting-types (list 'date 'exact-time
'register-order)) but it should really be (define date-sorting-types (list
'date 'exact-time 'reconciled-date))

*What would be the consensus from wizards if we had to do it right?*

I suggest:
1. We change (define date-sorting-types (list 'date 'exact-time
'reconciled-date))
2. When sorting by register-order, it should disallow date-subtotals

My solution to produce my report correctly requires a custom sorting
algorithm which is nearly complete, and would override the
qof-query-set-sort-order. Work-in-progress at
https://github.com/christopherlam/gnucash/commits/master-fix-grouping-
by-date

[1] this bug relates to my preferred sorting/grouping: prime-sortkey=date,
subtotal=quarterly, sec-sortkey=account-name, subtotal=true. This will
produce an incorrect grouping whereby a quarter (eg 2016 Q1) will be split
incorrectly, because the query will sort by dates rather than quarters.
Documented in my comment on
https://bugzilla.gnome.org/show_bug.cgi?id=626385



Christopher,



I would expect “Register Order” to mean the normal sorting order of
transactions in the register:

date-posted, num, date-entered, 

Re: Changing to C++

[Bob Gustafson]

I can put in a good word for Nim ( http://nim-lang.org/ )

It is as fast as C++ (compiles to C/C++), has intelligent (per-thread) 
garbage collection, a robust type system (if it compiles, chances are it 
is correct) and has a very lean syntax.


It also works well with Postgresql (probably also MySql, but I use 
post). It is worth taking a look at.


Developing with Nim can be a lot faster than with C++. The lean syntax 
helps a lot.


The front-end can also target Javascript for GUI development, although I 
have not used that feature.


Best regards - BobG

On 06/04/2017 10:59 PM, Leon Taylor wrote:

Hi all,

I recently saw the blog post on how the project is going to be re-written
in C++.
I understand that I am not to decide where the project goes or what happens
to it, but if it is not to late, I personally think that we should re-think
making the change to C++.
I understand the GObject is a pain in the ass to use and learn, and that
C++ is a better choice for developing desktop software (not to mention that
there more libraries available for C++), but I (personally) think that
re-writing the source code is counter-productive.
Many people do not want to use C++, as it is very complex and hard to use
properly. I know that you said it would be easier for people to learn C++
than GObject, but I disagree. Many people know C and how to use it
PROPERLY, whereas only experienced C++ developers can use it properly. I
think the only thing changing to C++ would do is scare off contributors.
This is just *my *opinion, so just take it with a grain of salt. Please
tell me if I have misunderstood something or taken something the wrong way.

Thanks, Leon.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Development environment on mac

[Bob Gustafson]

Congratulations..

I use Homebrew - and get all my usual Linux tools. No dual boot, no 
plugins, just brew.


You might also sign up as an Apple Developer (now free as I recall). You 
can then download Xcode and some additional command-line tools. But 
Homebrew is the main toolbox.


You also might switch from the GNU C++ compiler to Clang, which is the 
normal OSX C++ compiler (also available for Linux). Clang gives better 
diagnostic messages. The compile speed and execution speed is about the 
same as GNU.


Have fun - BobG


On 10/21/2016 09:05 AM, Phil Longstaff wrote:

For a project I am involved with, I may need to move to a macbook as my
development environment. Because my old windows/linux laptop is getting old
and parts are no longer working, it may no longer be available to me. So, I
may need to do any future gnucash development on apple products.

For those here who use mac, what can you tell me? Are the tools we need
readily available? Do you just dual-boot to linux or use a linux vm? What
do you use?

Phil
___


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Lots In Account

[Bob Gustafson]

"Lots" are important when figuring capital gains taxes (in the US anyway).

When partially selling a stock position, it is useful to know when the 
lots were purchased. If more than one year in the past, that lot 
qualifies for a lower tax.


If there are losses in a stock position, it may be advantageous to sell 
lots having been purchased less than one year ago - as Uncle Sam helps 
out paying some of the losses.



On 10/09/2016 10:33 AM, Geert Janssens wrote:

On Sunday 09 October 2016 11:51:46 Chris Good wrote:

I'd like to also briefly mention that the Lots in Account window is
used for business functions for the links between invoices and
payments/credits.



Can some-one please confirm that in the business functions, the Lots
in Account window is used ONLY for viewing links between invoices and
credits?

I assume any actual linking should only be done by the business
functions, not this window?

In the context of business features the Lots in Account window is not
used in normal operation. In this context the lots are generated and
manipulated internally by the code and should normally not be used
directly. The only reason to go to the Lots in Account window is to
correct mistakes that are hard to correct otherwise (either due to bugs
in past versions of gnucash or due to unintended use of said features).
Some of these use cases are found on this wiki page
http://wiki.gnucash.org/wiki/Business_Features_Issues





On a side issue, there was a question recently on gnucash-user from
some-one else about trying to use lots for capital gain/loss of
currencies (commodities?), and I didn't see any response.

Can any-one confirm this is possible or is it just wishful thinking?


I don't know about this.


Likewise, I was wondering it is possible to use lots for capital
gain/loss of (possibly depreciated) fixed assets?


Same here.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Server/Client?

[Bob Gustafson]

On 05/03/2016 08:02 PM, John Ralls wrote:


On May 3, 2016, at 10:16 AM, Don Ireland  wrote:

I’ve been using gnuCash for the past 3-4 days and really like what I’ve seen so 
far.  I’ve read that the dev team is planning to rewrite the code.

Might I suggest breaking it into a server (with an API) and a client (providing 
the GUI)?  This would allow for the GUI to be used on any multitude of devices 
and device types.  This would also address the current need for users that are 
using a MySQL back-end to be experienced with MySQL.  My vision of this is to 
embed SQLite into the server code directly.  Then the server would maintain 
SQLite file for its data.

· A client would communicate with it via API calls to create transactions, 
accounts & scheduled transactions.
· A client would communicate with it to get an updated list of these 
records as well.
· If the client is unable to communicate with the server, then the 
client can not modify an existing record but would be able to create NEW 
records which would be stored locally in a queue.  When a connection to the 
server becomes available, the queue would be processed and new records would be 
added.
· If the client is able to communicate with the server, then the client 
can “CHECK OUT” a record for editing (which COULD include delete).
· Whenever the server receives any updates, it would push the changes 
out to all the other devices that are “Subscribed”.  This would use the Google 
Cloud Messaging system to push these notifications which the clients would 
automatically process.  The notification would tell the clients specifically 
which records that they need to download it order to get these updates.
· The server would handle creating any new transactions that are the 
result of Scheduled Transactions (to avoid having conflicts with the clients 
trying to create them.

The server could be installed on the same pc as the GUI thus creating more of a 
"local install" if that's what is needed.  The server could be installed on a 
Raspberry Pi, an individual computer or a full fledged server.

Having done this, anytime someone comes up with a new device (new smart phone 
OS for example), a developer would just need to create a gui client that 
communicates with the server.  Someone could even create a gui that works via 
PHP thus enabling a web view (similar to using php to create a web interface 
for an IMAP account).  This would also make it easier to develop EXTENSIONS (to 
tie in a custom CUSTOMER MANAGEMENT SYSTEM or similar).

One might say this is not very friendly for a user who isn't tech savvy but I 
would argue that for the most part someone who isn't tech savvy is probably 
buying commercial software (quicken).  If a non-savvy person IS using gnuCash, 
it was probably set up for them by someone who IS tech savvy.
Don Ireland
_
  
There's a single-application pattern for separating the guts from the GUI called Model-View-Controller, or MVC for short. GnuCash is halfway there but there's a lot of controller code and even some model code that's found itself in the GUI code and needs to be cleaned back out. Volunteers needed to speed up that process.


You seem to be a bit confused about task separations, though. Either the 
processing happens on the server and only display events are sent and received 
by the GUI client (XWindows would be an extreme example) or the processing 
happens on the client and the server handles the database transactions (the 
planned design we're working towards, with a SQL backend). Having both ends 
able to do processing means that you have to control concurrency somewhere in 
the middle. That's harder and not really useful.

GnuCash already has infrastructure in place for extensions. It's used extensively in the 
program's internals, and is reflected in all of those "loading" messages that 
make start up so slow.

Regards,
John Ralls


Yes, MVC is the way to go - and is the pattern used in Ruby on Rails for 
example.


If the 'state' is stored only in the database (again, like Ruby on Rails 
- the Model part of MVC), then concurrency is handled by the database.


Postgresql (for example) does an excellent job of handling concurrency - 
no extra sweat by the application programmer.


To make the programming easier - there are IDEs available. I use 
RubyMine for RoR applications.


Regards - Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Server/Client?

[Bob Gustafson]

Sounds like a progressive idea.

A very similar approach which would be easier and more ‘main stream’ is to use 
a browser as the GUI. There are a number of frameworks which can be used to 
write the server such as RubyOnRails, Django, etc. These frameworks use MySql, 
Postgresql, SQLite in a database agnostic fashion.

Bob G

> On May 3, 2016, at 09:16, Don Ireland  wrote:
> 
> I’ve been using gnuCash for the past 3-4 days and really like what I’ve seen 
> so far.  I’ve read that the dev team is planning to rewrite the code.
> 
> Might I suggest breaking it into a server (with an API) and a client 
> (providing the GUI)?  This would allow for the GUI to be used on any 
> multitude of devices and device types.  This would also address the current 
> need for users that are using a MySQL back-end to be experienced with MySQL.  
> My vision of this is to embed SQLite into the server code directly.  Then the 
> server would maintain SQLite file for its data. 
> 
> · A client would communicate with it via API calls to create 
> transactions, accounts & scheduled transactions. 
> · A client would communicate with it to get an updated list of these 
> records as well.
> · If the client is unable to communicate with the server, then the 
> client can not modify an existing record but would be able to create NEW 
> records which would be stored locally in a queue.  When a connection to the 
> server becomes available, the queue would be processed and new records would 
> be added.
> · If the client is able to communicate with the server, then the 
> client can “CHECK OUT” a record for editing (which COULD include delete).
> · Whenever the server receives any updates, it would push the changes 
> out to all the other devices that are “Subscribed”.  This would use the 
> Google Cloud Messaging system to push these notifications which the clients 
> would automatically process.  The notification would tell the clients 
> specifically which records that they need to download it order to get these 
> updates. 
> · The server would handle creating any new transactions that are the 
> result of Scheduled Transactions (to avoid having conflicts with the clients 
> trying to create them. 
> 
> The server could be installed on the same pc as the GUI thus creating more of 
> a "local install" if that's what is needed.  The server could be installed on 
> a Raspberry Pi, an individual computer or a full fledged server. 
> 
> Having done this, anytime someone comes up with a new device (new smart phone 
> OS for example), a developer would just need to create a gui client that 
> communicates with the server.  Someone could even create a gui that works via 
> PHP thus enabling a web view (similar to using php to create a web interface 
> for an IMAP account).  This would also make it easier to develop EXTENSIONS 
> (to tie in a custom CUSTOMER MANAGEMENT SYSTEM or similar).
> 
> One might say this is not very friendly for a user who isn't tech savvy but I 
> would argue that for the most part someone who isn't tech savvy is probably 
> buying commercial software (quicken).  If a non-savvy person IS using 
> gnuCash, it was probably set up for them by someone who IS tech savvy. 
> Don Ireland
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Recommendations on Coding programs

[Bob Gustafson]

On 10/17/2015 10:49 PM, Bob Gustafson wrote:

On 10/17/2015 08:08 PM, Mike or Penny Novack wrote:

On 10/17/2015 7:06 PM, Matt Graham wrote:

G’day all,

Now that I finally have myself set up to be able to view, edit and 
test the gnucash sources, I have come across the limitation of using 
text editors (using nano at the moment...) to code. Can anyone 
recommend a good program for doing coding for Gnucash? I’m mainly 
looking at the C side of things rather than guile, but a program 
that can do multiple types of code would be useful. Preferably ones 
that are supported on both windows and linux.


Cheers,

Matt G
Well during several decades writing software for a living, I wrote* a 
few hundred thousand lines of code without a language sensitive 
editor. But since these are now readily available, I strongly 
recommend you use one. In any 'nix operating system this is no 
problem at all, since the standard library of utilities will give you 
a choice of them.


Under Windows you probably have a choice of at least some of these. 
Many decades back a friend sent me a copy of xemacs for Windows, so I 
know that one existed at least that far back << I was using it just 
to be able to do LISP under Windows >>


Michael D Novack

* I don't mean I entered that many keystroke by keystroke! Folks who 
are experienced at the trade usually know where to find "useful 
chunks" and have decent personal libraries from which chunks perhaps 
as big as hundreds of lines can be grabbed and used with just a few 
key changes.

___


You could take a look at the products available from 
https://www.jetbrains.com/


They are not free - but are modestly priced.

For C and C++, you might take a look at CLion 
https://www.jetbrains.com/clion/?fromMenu


I myself am using RubyMine and WebStorm.

Have fun

Bob G


For open source projects, you can apply for a free subscription:

  https://www.jetbrains.com/buy/opensource/?product=clion

Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Recommendations on Coding programs

[Bob Gustafson]

On 10/17/2015 08:08 PM, Mike or Penny Novack wrote:

On 10/17/2015 7:06 PM, Matt Graham wrote:

G’day all,

Now that I finally have myself set up to be able to view, edit and 
test the gnucash sources, I have come across the limitation of using 
text editors (using nano at the moment...) to code. Can anyone 
recommend a good program for doing coding for Gnucash? I’m mainly 
looking at the C side of things rather than guile, but a program that 
can do multiple types of code would be useful. Preferably ones that 
are supported on both windows and linux.


Cheers,

Matt G
Well during several decades writing software for a living, I wrote* a 
few hundred thousand lines of code without a language sensitive 
editor. But since these are now readily available, I strongly 
recommend you use one. In any 'nix operating system this is no problem 
at all, since the standard library of utilities will give you a choice 
of them.


Under Windows you probably have a choice of at least some of these. 
Many decades back a friend sent me a copy of xemacs for Windows, so I 
know that one existed at least that far back << I was using it just to 
be able to do LISP under Windows >>


Michael D Novack

* I don't mean I entered that many keystroke by keystroke! Folks who 
are experienced at the trade usually know where to find "useful 
chunks" and have decent personal libraries from which chunks perhaps 
as big as hundreds of lines can be grabbed and used with just a few 
key changes.

___


You could take a look at the products available from 
https://www.jetbrains.com/


They are not free - but are modestly priced.

For C and C++, you might take a look at CLion 
https://www.jetbrains.com/clion/?fromMenu


I myself am using RubyMine and WebStorm.

Have fun

Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Online banking

[Bob Gustafson]

I would second that recommendation.

A web scraper solution is captive to any random changes that the bank 
makes to its website - incurring a need to work on your parser before it 
'works' again.


Changes to bank web sites seem to come at the worst possible moment in 
terms of your own (developer) workload.


Even if a bank allows transaction downloads in various different formats 
(MT940, CSV(??),CAMT,..) the standards of individual banks and 
individual accounts can change over time (character set, whether to use 
UE or u-umlaut, all upper case vs upper/lower). Misspelling of names and 
other user-entered data is sometimes an unavoidable complication.


Data input is a complicated  game.

Have fun

Bob G

On 09/28/2015 01:40 AM, Christian Stimming wrote:

Dear Paul,

I don't think it is possible or useful to think of "yet another generic API".
Instead, I would suggest the API of aqbanking is indeed the 4th or 5th
iteration on building an API from the application to online banking functions.
Also, I would strongly suggest against programming a website scraper - it will
give you very little gain for very large effort. If your bank doesn't have
anything else besides a website, in fact the easiest solution is to find a
different bank that has some standard protocol such as OFX. Sorry for that.

Regards,

Christian

Am Montag, 28. September 2015, 00:24:02 schrieb Paul Tirk:

Hi,

no, I know that it's not a website scraper but in fact I want to program
one ;) And I assume the developer of AqBanking will not just add any set
of api-calls/https-requests for every other bank to his library.

So I was thinking about a generic interface in Gnucash to simplify
things because I also think it would be beneficial for future
development to not depend completely and only on AqBanking like it is
now because it seems that (at least in Europe) the trend is going away
from standards (except HBCI in Germany) towards bank-specific APIs (most
of them are https-requests sent).

Regards,

Paul

Am 27.09.2015 20:55, schrieb Derek Atkins:

Hi,

Yes, the GnuCash AqB backend is tied to AqB.  However...

AqBanking is licensed under the GPL, and already has multiple modules
that
implement HBCI, OFX, OFX-DC, MT940, CSV, ...

So, why do you feel that you couldn't add a new module to that?

Do you know what online banking protocol your bank supports?  Or do you
have the mistaken impression that it's a website scraper?

-derek

On Sun, September 27, 2015 2:23 pm, Paul Tirk wrote:

Hello!

I was thinking about adding online banking support for a bank which
has
no HBCI (and is not supported by AqBanking). After some time browsing
the source of gnucash and AqBanking I realized that the online banking
functionality of gnucash is tightly coupled to AqBanking which in turn
has a restricted license and it actually doesn't look easy to add
different banks.

Are there plans on a clean online banking API in gnucash which could
enable developers to include different banking protocols? If not I
would
be interested in contributing but I have no idea where to start. Could
somebody maybe give me a hint about this?

My idea would be: the current menu entries for online banking are
fine,
it would just need a general user/account setup which could allow the
current AqBanking accounts as well as other "plugins/modules" which
can
then be triggered as it is working right now with only AqBanking.

I hope I made myself clear and thanks in advance,

Paul
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Difficulty building on MacOSX (Mike Alexander)

[Bob Gustafson]

Or Homebrew (brew)

Bob G

 On May 8, 2015, at 11:30, Glen Jones g...@jones.no-ip.net wrote:
 
 Mike try looking at FINK (i.e. download and install) use that to
 download gnucash, then build from from source.
 
 It will get everything you need to compile GNU CASH, and build it. :)
 Then if you wish to lookat/change the source you can; as you know you
 have all the dependencies and appropriate make files.
 
 It might fast track you if you want to build from scratch changing whats
 linked in and some of the GNUCash build options.
 
 Hope thats clear/helps
 Glen
 
 
 On Fri, 2015-05-08 at 12:00 -0400, gnucash-devel-requ...@gnucash.org
 wrote:
 Send gnucash-devel mailing list submissions to
  gnucash-devel@gnucash.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 or, via email, send a message with subject or body 'help' to
  gnucash-devel-requ...@gnucash.org
 
 You can reach the person managing the list at
  gnucash-devel-ow...@gnucash.org
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of gnucash-devel digest...
 
 
 Today's Topics:
 
   1. Re: Difficulty building on MacOSX (Mike Alexander)
 
 
 --
 
 Message: 1
 Date: Thu, 07 May 2015 16:58:47 -0400
 From: Mike Alexander m...@umich.edu
 To: John Ralls jra...@ceridwen.us
 Cc: gnucash-devel@gnucash.org
 Subject: Re: Difficulty building on MacOSX
 Message-ID: 54a9482539df7d416d66d...@bayswater.msalexander.com
 Content-Type: text/plain; charset=utf-8; format=flowed
 
 --On May 7, 2015 at 7:19:49 AM -0700 John Ralls jra...@ceridwen.us 
 wrote:
 
 Surely you didn?t rebuild libc just to get a 64-bit time_t. What
 motivated you? Since you went to the work of replacing libc and the
 headers in your SDK (and have to redo it every time Apple pushes an
 Xcode upgrade), why not upgrade your TZ database as well?
 
 
 No, I didn't rebuild libc or anything like that.
 
 When I compile gnc-timezone.cpp the command used is
 
 clang++ -DHAVE_CONFIG_H -I. -I../../../../../gnucash/src/libqof/qof 
 -I../../.. -I../../../../../gnucash/lib/libc 
 -I../../../../../gnucash/src -D_REENTRANT -I/opt/local/include/glib-2.0 
 -I/opt/local/lib/glib-2.0/include -I/opt/local/include 
 -I/opt/local/include -DG_LOG_DOMAIN=\qof\ -I/opt/local/include 
 -DDUMP_FUNCTIONS -Werror -Wall -Wno-unused -Wno-deprecated-register 
 -std=gnu++11 -g -O0 -MT gnc-timezone.lo -MD -MP -MF 
 .deps/gnc-timezone.Tpo -c 
 ../../../../../gnucash/src/libqof/qof/gnc-timezone.cpp  -fno-common 
 -DPIC -o .libs/gnc-timezone.o
 
 In this compilation, time_t is defined in 
 /usr/include/sys/_types/_time_t.h as
 
   typedef __darwin_time_t time_t;
 
 __darwin_time_t is defined in /usr/include/i386/_types.h as
 
   typedef long __darwin_time_t;
 
 I'm using
 
 Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
 Target: x86_64-apple-darwin14.3.0
 Thread model: posix
 
 to compile this.   It's located in /usr/bin/clang++.
 
 In that compilation sizeof(long) is 8.
 
 /etc/localtime is a symlink to /usr/share/zoneinfo/America/Detroit 
 which was last changed on Nov. 16.  I've never touched that file, or 
 either of the include files, myself.  I don't know why my machine is 
 different from yours.
 
  Mike
 
 
 
 
 
 --
 
 Subject: Digest Footer
 
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel
 
 
 --
 
 End of gnucash-devel Digest, Vol 146, Issue 10
 **
 
 
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New user feedback

[Bob Gustafson]

You could go with Postgresql. The corresponding viewer/tool is pgAdmin 
III - both free, both excellent.


Bob G

On 02/23/2015 12:57 AM, Paul wrote:

Thanks for the idea John.

I had look around for an sqlite tool for analysing the database.

Theres a nice little sqlite reader/editor called sqliteman. However, 
when i try to open the gnucash database it responds with:


Unable to open or create file accounts.gnucash. It is probably not a 
database


I also found a free reporting tool for sql called openRPT but this 
requires an interface to sqlite as its designed for proper 
databases. The only interface i found is qsqlite which the developer 
has declared obsolete and it needs sqlite 2.8. Clearly not a good path 
to go down.


Does anyone know of any tools (for linux) that will empower me to view 
and/or create reports from the database?





On 23/02/15 01:11, John Ralls wrote:



On Feb 22, 2015, at 4:04 PM, Bob Gustafson bob...@rcn.com wrote:


On 02/22/2015 05:48 PM, John Ralls wrote:

On Feb 22, 2015, at 3:37 PM, Paul p.matth...@inbox.com wrote:

Hello all

I admire what you are trying to do and wish to support you with 
some feedback.


My usecase: We want to see whats happening to our money.

I downloaded and installed gnucash a couple of days ago because 
the need arose to manage our accounts. After connecting to online 
banking services and downloading all our transactions I got 
everything working perfectly. AWESOME!!  Problem solved I thought 
as I proceeded to the reporting to pull out some data for my 
partner...


What a disappointment. The stock reports are imo ugly and 
inadequate for our use case. We are interested in cash flow and 
the editing options for this report are minimal. Very minimal.


Being a qualified programmer I investigated the options for 
customising our reports somehow. I quickly found the answer to all 
of my reporting woes. I have to learn not one, but two obscure 
programming langages, namely guile/eguile and scheme.


In conclusion: I can't be bothered. I will have a look for 
something else that can output beautiful, professional and, if 
necessary, customizable reports.


I will report back with my findings if you like.

Actually, Guile and Scheme are the same language.
You might consider the SQL backend; one variant, SQLite3 requires 
no server. Using that instead of the default XML backend will allow 
you to query the database with standard SQL tools and use a 
SQL-based report writer to generate prettier reports.


Regards,
John Ralls


That is a great idea John - SQL report generation is quite a 
flexible solution.


I forgot to throw in the usual caveat: There’s at least one spot in 
the current release, the company information on the Business tab in 
the FileProperties dialog, that isn’t correctly synced to the SQL 
backend. That’s fixed for the next release, and in the meantime you 
can use FileSave As to force a complete rewrite of your database to 
save it if you need to. There may be other bits that I don’t know 
about, though I just did another thorough audit and I didn’t find 
any. Also you mustn’t write to the database except with GnuCash as 
all of the business logic is in GnuCash, not in the database. We 
haven’t even declared foreign keys in the database tables.


Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel




FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New user feedback

[Bob Gustafson]

On 02/22/2015 05:48 PM, John Ralls wrote:

On Feb 22, 2015, at 3:37 PM, Paul p.matth...@inbox.com wrote:

Hello all

I admire what you are trying to do and wish to support you with some feedback.

My usecase: We want to see whats happening to our money.

I downloaded and installed gnucash a couple of days ago because the need arose 
to manage our accounts. After connecting to online banking services and 
downloading all our transactions I got everything working perfectly. AWESOME!!  
Problem solved I thought as I proceeded to the reporting to pull out some data 
for my partner...

What a disappointment. The stock reports are imo ugly and inadequate for our 
use case. We are interested in cash flow and the editing options for this 
report are minimal. Very minimal.

Being a qualified programmer I investigated the options for customising our 
reports somehow. I quickly found the answer to all of my reporting woes. I have 
to learn not one, but two obscure programming langages, namely guile/eguile and 
scheme.

In conclusion: I can't be bothered. I will have a look for something else that 
can output beautiful, professional and, if necessary, customizable reports.

I will report back with my findings if you like.

Actually, Guile and Scheme are the same language.
You might consider the SQL backend; one variant, SQLite3 requires no server. 
Using that instead of the default XML backend will allow you to query the 
database with standard SQL tools and use a SQL-based report writer to generate 
prettier reports.

Regards,
John Ralls


That is a great idea John - SQL report generation is quite a flexible 
solution.


Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Book-currency feature and cost accounting

[Bob Gustafson]

On 10/10/2014 09:40 PM, John Ralls wrote:

On Oct 10, 2014, at 4:14 PM, Alex Aycinena alex.aycin...@gmail.com wrote:


John,

On Thu, Oct 9, 2014 at 5:26 PM, John Ralls jra...@ceridwen.us wrote:

Alex,

How much clean-up/refactoring and C++ conversion are you willing to do in the 
process?

I am willing to do some when I spot an opportunity, or it is pointed out to me. 
May I consult you about this?

Of course.

[SNIP]


Be careful with automatically invoking the lots facility: In the usual 
multi-currency transaction there is no potential for capital gain because the 
holding period of the “foreign” currency is 0. That case is making a purchase 
or sale of something in a foreign currency which is immediately converted to 
one’s home currency. Even when the user has long-term holdings of the “foreign” 
currency that *are* subject to capital gains and losses, those immediate 
transactions won’t and shouldn’t clutter up the database with 0-value cap gain 
splits.


I agree with you here. If someone, for example, use their credit card in a foreign 
country (essentially 'buying' the foreign currency and then immediately spending it), 
then I don't think lots would be involved as long as both accounts are in the 
book-currency. If the user has a long-term holding in the foreign currency, 
and then spends it, the system would have a cost for that holding, and if the cost is 
used to value the spend, then there would be no capital gain/loss. If the uses wishes to 
value the spend at, say, the then current exchange rate, then the system has the data to 
calculate and show the resulting gain/loss and create the split to the account specified 
for the account (with the user option to override).

Right. The credit card transaction in particular has the potential to ignore the 
foreign currency. I was thinking more of the people who track cash in 
wallet. If I'm visiting
(my family says Japan is next) and get 1JPY from the ATM I'd need a Cash 
and some Expense accounts in JPY to account for spending that cash. Since those 
transactions
wouldn't be in the book currency (USD in my case) I'd be presented with a 
Transfer dialog box for each, and might select a different exchange rate from 
the one used for the
ATM withdrawal, inadvertently creating a wholly bogus cap gain/loss. That's all 
entirely hypothetical, I treat cash as an expense category and don't worry much 
about how
I spend it because in general I don't use it that much., but since Cash in 
Wallet is one of the accounts in the templates I'm sure there are others who do 
track it.

Regards,
John Ralls


Decades ago, when I was doing more international business travel, I kept 
track of my money exchange receipts and periodically counted the cash in 
my pocket and wrote it down. I had a little basic program that tracked 
my business and personal expenses.


Because I would exchange money at different times (and rates), it was 
possible to assign the more favorable exchange rates to my personal 
expenses. I don't know whether this minor 'profit' ever approached 
paying for the (slight) extra time needed to keep track of things, but 
it was fun.


Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[Bob Gustafson]

On 05/21/2014 08:59 AM, John Ralls wrote:

On 20 May 2014, at 22:45, Bob Gustafson bob...@rcn.com wrote:


On 05/20/2014 07:20 PM, John Ralls wrote:

On May 20, 2014, at 4:02 PM, Bob Gustafson bob...@rcn.com wrote:

No, I am not doing it in GnuCash - but I wish I could.

My comment is to encourage any effort in the direction of time and timezone 
support and discourage attempts to close off that path.

I don’t think that that’s a direction we want to go. I can’t see many users 
making the effort to include the time they wrote a check, or swiped their debit 
card, or whatever. FWIW, one CC company seems to post everything at 1700. Every 
transaction looks like
   STMTTRN
 TRNTYPEDEBIT
 DTPOSTED2014012117.000

Everybody else I use just reports posted dates.


As an example, here is a box of chocolates complete with timestamps..

viewspread13.27.csv:1234567809/23/2013  -40.32  EINZUG 
AUSLANDSLASTSCHRIFT|9208|CHF  49,50KURS1,2276000|KURS VOM 20.09.13
MAFD|ZUERICH-FL AM19.09.13 15.50|  LINDT ZRH CHXR  CHE| 1001|  
959566027|  EC-POSMAGNET6   GEB.EU 0,00|002|

I see two dates and one timestamp. The timestamp may or may not be useful; 
there’s no way of knowing without detailed information from the bank about what 
it means. Here’s one guess: You made a purchase for CHF49.50 at 1550 on 19 Sept 
2013 in Zurich. It was posted to the seller’s bank on 20 Sept and to your bank 
at $40.32 on the 23rd. That’s an effective exchange rate of $1.230/CHF.
The rates, according to 
http://www.exchangerates.org.uk/CHF-USD-exchange-rate-history-full.html,
were

Monday 23 September 20131 CHF = 1.0979 USD
Sunday 22 September 20131 CHF = 1.0984 USD
Saturday 21 September 2013  1 CHF = 1.0987 USD
Friday 20 September 20131 CHF = 1.0987 USD
Thursday 19 September 2013  1 CHF = 1.0979 USD

The actual rate used by the banks could have been any of those, or something else, 
but the spread is $.0008, or  4¢ on the transaction out of the $4.25 the bank 
charged you. Talk about sweating the small stuff. I don’t see how you gain 
anything at all by knowing you made the purchase — or whatever actually happened — 
at 1550.

Regards,
John Ralls

Pretty good analysis!

The exchange was into Euros, so the historical exchange rate would have been:

Head-slap D'oh.

Monday 23 September 20131 CHF = 0.8136 EUR  or 40.2732 EUR
Sunday 22 September 20131 CHF = 0.8120 EUR  or 40.1940
Saturday 21 September 2013  1 CHF = 0.8124 EUR  or 40.2138
Friday 20 September 20131 CHF = 0.8124 EUR  or 40.2138
Thursday 19 September 2013  1 CHF = 0.8115 EUR  or 40.1692

The actual euros deducted was -40.32 and the CHF spent was 49.50 or an exch 
rate of 0.8145

Picking the rate of 0.8124 gives a Euro deduction of 40.2138 - the actual 
deduction was 40.32, so whatever exchange rate the banks used, they did not 
lose money.

(The convenience of using a plastic card at the point of sale is certainly 
worth 10 euro cents!)

---

All of this analysis and reporting can be done without human keystrokes, as 
long as the data is available. The fact that the transaction was done on a 
Thursday at 15:50 and not reported until the following Monday rather increases 
the time slop.

Suppose that the transaction was done at 12:50 and that was early enough to 
make an earlier bank forex time window and the deduction could then be reported 
on Friday 20 Sept (yes, unlikely..)

With enough transactions, some of these details of the forex mechanism could be 
teased out of an otherwise very boring bunch of numbers.

But irrelevant to GnuCash, because from the standpoint of your own books, only 
the entry date of the transnaction -- the date that you recognize the payment 
in your book -- is relevant and recorded. The date it's recognized by the 
merchant's bank and by your bank isn't part of your book, it's part of theirs, 
and so there's no reason to record it in GnuCash. The time the transaction is 
posted in the merchant's book, which is the only one you have, is also 
irrelevant and tells you nothing about the forex transaction, which took place 
sometime between being posted to the merchant's bank and to yours.

The best tool for playing with that sort of analysis is a spreadsheet program, 
which is no doubt what you're using.

Regards,
John Ralls



I have control of the purchase date/time. In the ideal case, the 
date/time of payment from the bank account should be a few milliseconds 
later. If it is longer (like 3.5 days..), you might say that the banking 
system is loaning me money for that time period. This time period is 
interesting to me.


On my personal credit card, I am aware of the date the monthly statement 
closes. If I purchase stuff just after this date, my bank 'loan' is for 
a longer period.




The programs I use are a parser and database to load up the data from 
downloaded bank transactions

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[Bob Gustafson]

On 05/20/2014 09:41 AM, John Ralls wrote:

On May 20, 2014, at 1:55 AM, Geert Janssens janssens-ge...@telenet.be wrote:


On Tuesday 20 May 2014 02:41:55 Mike Alexander wrote:

--On May 19, 2014 7:07:46 PM -0400 John Ralls
jra...@code.gnucash.org
wrote:

Updated  via  https://github.com/Gnucash/gnucash/commit/eabaee8e
(commit)from  https://github.com/Gnucash/gnucash/commit/6e62ce99
(commit)



commit eabaee8eb58c557743b8b1b476b4145b97eb9836
Author: John Ralls jra...@ceridwen.us
Date:   Thu May 15 17:04:26 2014 -0700

A truly ancient bug, discovered with an Xcode-5.1 compiler

warning.

Should this go on maint?


While this is a bug I think it would not have had any influence in
practise because the loop always breaks before the end of the string is
reached for all known date formats.

Yeah, obviously that condition never mattered in practice because it would 
never be false.


But I have backported the fix to maint anyway.


And perhaps this is a good moment to point out that the routine itself
is flawed and should be improved during the conversion to
boost::datetime.

The issue with this routine is that it assumes that short date formats
consist of only digits and a separator for all known locales. This is
false. There are several oriental locales for which the short date
format starts with a day-of-the-week field. For these locales the
dateSeparator routine will return the first character of today's day of
the week instead of the real separator. So every day of the week it
would discover a different separator.

This is strongly related to bug
https://bugzilla.gnome.org/show_bug.cgi?id=497831 although the
dateSeparator routine is only one part of the problem. The other part is
the code that tries to guess an incompletely entered date in the
register code. That part trips over the day-of-week part as well.

Hopefully boost::datetime can help here.

I sure hope so. It has its own parsers and formatters that I hope will do 
everything we need.

One other thing I intend to do in that change is get rid of the 
entry-date-changes-with-timezone problem forever by making entry-date a plain 
date, no time component and no timezone. ISTM posted date should continue to be 
a full timestamp. Are there any other date-times where it's important that they 
should be one or the other?

Regards,
John Ralls
It is useful to have time and timezone on transactions that may involve 
a change of currency. Even within one country and currency (US) it is 
possible to have transactions occurring in different timezones.


I would vote to retain the possibility of entering time and timezone, 
even if the user chooses to ignore those fields.


The multiple currency, global nature of Gnucash is one of its attractive 
features. Time is important.


Bob G
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[Bob Gustafson]

On 05/20/2014 10:11 AM, Geert Janssens wrote:

On Tuesday 20 May 2014 10:02:32 Bob Gustafson wrote:

On 05/20/2014 09:41 AM, John Ralls wrote:

On May 20, 2014, at 1:55 AM, Geert Janssens janssens-

ge...@telenet.be wrote:

On Tuesday 20 May 2014 02:41:55 Mike Alexander wrote:

--On May 19, 2014 7:07:46 PM -0400 John Ralls
jra...@code.gnucash.org

wrote:

Updated  via  https://github.com/Gnucash/gnucash/commit/eabaee8e
(commit)from
https://github.com/Gnucash/gnucash/commit/6e62ce99
(commit)



commit eabaee8eb58c557743b8b1b476b4145b97eb9836
Author: John Ralls jra...@ceridwen.us
Date:   Thu May 15 17:04:26 2014 -0700

 A truly ancient bug, discovered with an Xcode-5.1 compiler

warning.

Should this go on maint?

While this is a bug I think it would not have had any influence in
practise because the loop always breaks before the end of the
string is reached for all known date formats.

Yeah, obviously that condition never mattered in practice because it
would never be false.

But I have backported the fix to maint anyway.


And perhaps this is a good moment to point out that the routine
itself is flawed and should be improved during the conversion to
boost::datetime.

The issue with this routine is that it assumes that short date
formats consist of only digits and a separator for all known
locales. This is false. There are several oriental locales for
which the short date format starts with a day-of-the-week field.
For these locales the dateSeparator routine will return the first
character of today's day of the week instead of the real
separator. So every day of the week it would discover a different
separator.

This is strongly related to bug
https://bugzilla.gnome.org/show_bug.cgi?id=497831 although the
dateSeparator routine is only one part of the problem. The other
part is the code that tries to guess an incompletely entered date
in the register code. That part trips over the day-of-week part as
well.

Hopefully boost::datetime can help here.

I sure hope so. It has its own parsers and formatters that I hope
will do everything we need.

One other thing I intend to do in that change is get rid of the
entry-date-changes-with-timezone problem forever by making
entry-date a plain date, no time component and no timezone. ISTM
posted date should continue to be a full timestamp. Are there any
other date-times where it's important that they should be one or
the other?

Regards,
John Ralls

It is useful to have time and timezone on transactions that may
involve a change of currency. Even within one country and currency
(US) it is possible to have transactions occurring in different
timezones.


Please bear in mind that you can't enter such information in the current
version of gnucash either but it's recorded behind the scenes.

Until now I have only seen disadvantages of the fact that we keep track
of timezone and time information. Reports are off, scheduled
transactions trigger at the wrong time,...

Can you give an example where it would add value to keep timezone
information in GnuCash as it is now ?

Geert


I regularly look at transactions between the US and Germany. It is 
useful to track the time of the transaction in the US with the time of 
the deposit in Germany.


Synchronizing this with external events (currency exchange rates) it is 
possible to estimate how much the banks are charging above straight 
exchange rate.


Some days of the week are better than others.

Bob G


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[Bob Gustafson]

On 05/20/2014 05:16 PM, John Ralls wrote:

On May 20, 2014, at 2:28 PM, Bob Gustafson bob...@rcn.com wrote:


On 05/20/2014 10:11 AM, Geert Janssens wrote:

On Tuesday 20 May 2014 10:02:32 Bob Gustafson wrote:

On 05/20/2014 09:41 AM, John Ralls wrote:

On May 20, 2014, at 1:55 AM, Geert Janssens janssens-

ge...@telenet.be wrote:

On Tuesday 20 May 2014 02:41:55 Mike Alexander wrote:

--On May 19, 2014 7:07:46 PM -0400 John Ralls
jra...@code.gnucash.org

wrote:

Updated  via  https://github.com/Gnucash/gnucash/commit/eabaee8e
(commit)from
https://github.com/Gnucash/gnucash/commit/6e62ce99
(commit)



commit eabaee8eb58c557743b8b1b476b4145b97eb9836
Author: John Ralls jra...@ceridwen.us
Date:   Thu May 15 17:04:26 2014 -0700

 A truly ancient bug, discovered with an Xcode-5.1 compiler

warning.

Should this go on maint?

While this is a bug I think it would not have had any influence in
practise because the loop always breaks before the end of the
string is reached for all known date formats.

Yeah, obviously that condition never mattered in practice because it
would never be false.

But I have backported the fix to maint anyway.


And perhaps this is a good moment to point out that the routine
itself is flawed and should be improved during the conversion to
boost::datetime.

The issue with this routine is that it assumes that short date
formats consist of only digits and a separator for all known
locales. This is false. There are several oriental locales for
which the short date format starts with a day-of-the-week field.
For these locales the dateSeparator routine will return the first
character of today's day of the week instead of the real
separator. So every day of the week it would discover a different
separator.

This is strongly related to bug
https://bugzilla.gnome.org/show_bug.cgi?id=497831 although the
dateSeparator routine is only one part of the problem. The other
part is the code that tries to guess an incompletely entered date
in the register code. That part trips over the day-of-week part as
well.

Hopefully boost::datetime can help here.

I sure hope so. It has its own parsers and formatters that I hope
will do everything we need.

One other thing I intend to do in that change is get rid of the
entry-date-changes-with-timezone problem forever by making
entry-date a plain date, no time component and no timezone. ISTM
posted date should continue to be a full timestamp. Are there any
other date-times where it's important that they should be one or
the other?

Regards,
John Ralls

It is useful to have time and timezone on transactions that may
involve a change of currency. Even within one country and currency
(US) it is possible to have transactions occurring in different
timezones.


Please bear in mind that you can't enter such information in the current
version of gnucash either but it's recorded behind the scenes.

Until now I have only seen disadvantages of the fact that we keep track
of timezone and time information. Reports are off, scheduled
transactions trigger at the wrong time,...

Can you give an example where it would add value to keep timezone
information in GnuCash as it is now ?

Geert

I regularly look at transactions between the US and Germany. It is useful to 
track the time of the transaction in the US with the time of the deposit in 
Germany.

Synchronizing this with external events (currency exchange rates) it is 
possible to estimate how much the banks are charging above straight exchange 
rate.

Some days of the week are better than others.


That’s nice, but you’re not doing it in GnuCash. If you think you are you’re 
fooling yourself.

Regards,
John Ralls

No, I am not doing it in GnuCash - but I wish I could.

My comment is to encourage any effort in the direction of time and 
timezone support and discourage attempts to close off that path.


As an example, here is a box of chocolates complete with timestamps..

viewspread13.27.csv:12345678	09/23/2013		-40.32		EINZUG 
AUSLANDSLASTSCHRIFT|9208|CHF  49,50KURS1,2276000|KURS VOM 20.09.13 
  MAFD|ZUERICH-FL AM19.09.13 15.50|	LINDT ZRH CHXR  CHE| 
1001|	959566027|	EC-POSMAGNET6   GEB.EU 0,00|	002|	

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

[Bob Gustafson]

On 05/20/2014 07:20 PM, John Ralls wrote:

On May 20, 2014, at 4:02 PM, Bob Gustafson bob...@rcn.com wrote:

No, I am not doing it in GnuCash - but I wish I could.

My comment is to encourage any effort in the direction of time and timezone 
support and discourage attempts to close off that path.

I don’t think that that’s a direction we want to go. I can’t see many users 
making the effort to include the time they wrote a check, or swiped their debit 
card, or whatever. FWIW, one CC company seems to post everything at 1700. Every 
transaction looks like
   STMTTRN
 TRNTYPEDEBIT
 DTPOSTED2014012117.000

Everybody else I use just reports posted dates.


As an example, here is a box of chocolates complete with timestamps..

viewspread13.27.csv:1234567809/23/2013  -40.32  EINZUG 
AUSLANDSLASTSCHRIFT|9208|CHF  49,50KURS1,2276000|KURS VOM 20.09.13
MAFD|ZUERICH-FL AM19.09.13 15.50|  LINDT ZRH CHXR  CHE| 1001|  
959566027|  EC-POSMAGNET6   GEB.EU 0,00|002|

I see two dates and one timestamp. The timestamp may or may not be useful; 
there’s no way of knowing without detailed information from the bank about what 
it means. Here’s one guess: You made a purchase for CHF49.50 at 1550 on 19 Sept 
2013 in Zurich. It was posted to the seller’s bank on 20 Sept and to your bank 
at $40.32 on the 23rd. That’s an effective exchange rate of $1.230/CHF.
The rates, according to 
http://www.exchangerates.org.uk/CHF-USD-exchange-rate-history-full.html,
were

Monday 23 September 20131 CHF = 1.0979 USD
Sunday 22 September 20131 CHF = 1.0984 USD
Saturday 21 September 2013  1 CHF = 1.0987 USD
Friday 20 September 20131 CHF = 1.0987 USD
Thursday 19 September 2013  1 CHF = 1.0979 USD

The actual rate used by the banks could have been any of those, or something else, 
but the spread is $.0008, or  4¢ on the transaction out of the $4.25 the bank 
charged you. Talk about sweating the small stuff. I don’t see how you gain 
anything at all by knowing you made the purchase — or whatever actually happened — 
at 1550.

Regards,
John Ralls


Pretty good analysis!

The exchange was into Euros, so the historical exchange rate would have 
been:


Monday 23 September 20131 CHF = 0.8136 EUR  or 40.2732 EUR
Sunday 22 September 20131 CHF = 0.8120 EUR  or 40.1940
Saturday 21 September 2013  1 CHF = 0.8124 EUR  or 40.2138
Friday 20 September 20131 CHF = 0.8124 EUR  or 40.2138
Thursday 19 September 2013  1 CHF = 0.8115 EUR  or 40.1692

The actual euros deducted was -40.32 and the CHF spent was 49.50 or an exch 
rate of 0.8145

Picking the rate of 0.8124 gives a Euro deduction of 40.2138 - the actual 
deduction was 40.32, so whatever exchange rate the banks used, they did not 
lose money.

(The convenience of using a plastic card at the point of sale is certainly 
worth 10 euro cents!)

---

All of this analysis and reporting can be done without human keystrokes, as 
long as the data is available. The fact that the transaction was done on a 
Thursday at 15:50 and not reported until the following Monday rather increases 
the time slop.

Suppose that the transaction was done at 12:50 and that was early enough to 
make an earlier bank forex time window and the deduction could then be reported 
on Friday 20 Sept (yes, unlikely..)

With enough transactions, some of these details of the forex mechanism could be 
teased out of an otherwise very boring bunch of numbers.

Bob G

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Creating Non-US Tax Reports

[Bob Gustafson]

On 01/29/2014 11:41 AM, Alex Aycinena wrote:

-- Forwarded message --
From: Clint Redwood cl...@screwtape.co.uk
To: gnucash-devel@gnucash.org gnucash-devel@gnucash.org
Cc:
Date: Wed, 29 Jan 2014 16:29:03 +
Subject: Creating Non-US Tax Reports
Hi!

Apologies if this has been done to death but googling found nothing
relevant.

Is there any way of setting up custom tax codes against accounts, and to
use the tax reports to do UK personal and corporation tax. It doesn't
appear to be able to be done inside the application but I wondered if there
is a configuration file I could modify to enable me to use this report
effectively, rather than just showing US forms and boxes. Clearly the
export isn't going to be relevant, but just having the report would be
useful.

Any suggestions or pointers welcome.

Thanks!

Yours,

Clint Redwood

Screwtape Limited, Registered 06663232, Babington House, 26 College Road,
Chilwell, Nottingham NG9 4AS


There is no easy way to use the existing US-based report for non-US income

tax reporting. Of course it can be done with a bunch of re-programming.

I maintain this part of gnucash and plan in the future to make changes that
actually would allow this. For the US, since the current system is based on
'txf' codes, the maintenance of which is dormant, the system is gradually
getting stale; I would like to make the 'txf' code not the key but an
attribute of a hidden key so that new codes could be added even if no
'txf'' code exists for an item. If I do this in a fairly generalized way,
then it could be used to support multiple taxing jurisdictions (within the
US and outside of the US) simultaneously. If in an even more generalized
way, it could support user-managed tagging of accounts, transactions, and
splits, a feature which has also been asked for and I would like to use
personally. But this will take a bit of effort and time to accomplish.

Alex

Thanks much for your effort and future efforts.

Perhaps if you started with the idea of a user-managed tagging of 
accounts, transactions, and splits - it would be flexible enough to be 
useful without a lot of extra user keyboard effort.


I myself don't yet use GnuCash, but I would like to use it to centralize 
the storage of my (minimal) keystrokes and and be able to generate 
useful reports. My records are in various bank on-line bill paying 
systems that don't really record what I would like to record (such as 
the actual payee and why). If I dump these bank records (US banks), I 
only get 'CHECK 2014', '20.47'. Pretty dismal.


Many years ago, I was quite happy with Quicken for the Mac. Using the 
Checkfree feature, I could pay my bills and have good data stored on my 
own computer. But Quicken for the Mac has been gutted by Intuit and 
somehow the bill pay feature doesn't work the same way. Until recently, 
I was writing out checks by hand and mailing them.


I do have records downloaded from German accounts that are wonderful in 
their completeness (MT940 in UTF-8 character set). I process these using 
a program developed over a number of years. The key feature is a set of 
patterns which categorize all of the transactions. The MT940 files also 
have enough redundancy to give me some confidence in my own program. My 
balance equals the bank balance regularly over the past couple of years.


The categorization patterns require maintenance as the bank changes 
their standards over the years - the character set was only recently 
standardized on utf-8. Also, even though umlauts are possible in the 
character set (and my patterns..) the bank has recently chosen to use 
'UE' instead of the u with two dots over it. Thus my collection of 
patterns has many umlaut variations (as well as detecting infrequent 
mispelled data). The pattern file is currently 495 lines long. Bank data 
stretches back to 2006.


If your user-managed tagging could incorporate user-written regular 
expression patterns, I think it could go a long way toward satisfying a 
big range of GnuCash users.


Best regards

Bob G


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: configure has difficulty finding libgoffice

[Bob Gustafson]

On 01/19/2014 01:35 AM, Mike Alexander wrote:
--On January 19, 2014 1:21:50 AM -0600 Bob Gustafson bob...@rcn.com 
wrote:



I downloaded the source for gnucash about an hour ago.

I'm running ./configure and this is the end of the output - showing
problem:


What does

  pkg-config --modversion libgoffice-0.8

print?  You may need to set PKG_CONFIG_PATH or possibly PKG_CONFIG in 
your environment before running config.


Mike



I have lots of .pc files in the normal directory /usr/lib64/pkconfig, 
but the file for goffice is named for the latest library 
libgoffice-0.10, not the previous library libgoffice-0.8


There does seem to be a naming problem here - changing the configure.ac 
file so the library names match:


[user1@hoho6 gnucash-2.6.0]$ diff configure.ac configure.ac.orig
1009c1009
   PKG_CHECK_MODULES(GOFFICE, libgoffice-0.10 = 0.7.0, [goffice=1], 
[AC_MSG_ERROR([Cannot find libgoffice.= 0.7.0])])

---
   PKG_CHECK_MODULES(GOFFICE, libgoffice-0.8 = 0.7.0, [goffice=1], 
[AC_MSG_ERROR([Cannot find libgoffice.= 0.7.0])])

[user1@hoho6 gnucash-2.6.0]$

And then running autoconf to get a corrected configure script allows 
configure to step over that problem.


  The configure script now hangs on webkit-1.0...

This problem is fixed by doing:

  yum install webkitgtk-devel

After this tweek, the configure stage completes with the summary:

  Options detected/selected
  -
  gnucash version .. : 2.6.0
  Build for host ... : x86_64-unknown-linux-gnu
  Optional components... :  dbi
  Extra Warnings ... :  -Wdeclaration-after-statement
  CPPFLAGS . :
  CFLAGS ... :  -Wdeclaration-after-statement -g -O2 -Wall 
-Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused

  LDFLAGS .. :
  prefix : /usr/local

Now running 'make 21 | tee make.out' seems to re-run the configure 
script, but no problem with that.


However, make does end with a problem:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src 
-I../../../src/core-utils -I../../../src/engine 
-I../../../src/gnc-module -I../../../src/app-utils -I../../../src/gnome 
-I../../../src/gnome-utils -I../../../src/import-export 
-I../../../src/libqof/qof -I../../../lib/libc -I../../../lib -pthread 
-I/usr/include/guile/2.0 -pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include -pthread -I/usr/include/libgoffice-0.10 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/libgsf-1 -I/usr/include/libxml2 -I/usr/include/gtk-3.0 
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/gio-unix-2.0/ 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng15 
-I/usr/include/libdrm -DG_LOG_DOMAIN=\gnc.import.csv\ 
-Wdeclaration-after-statement -g -O2 -Wall -Wunused -Wmissing-prototypes 
-Wmissing-declarations -Wno-unused -MT assistant-csv-account-import.lo 
-MD -MP -MF .deps/assistant-csv-account-import.Tpo -c 
assistant-csv-account-import.c  -fPIC -DPIC -o 
.libs/assistant-csv-account-import.o

assistant-csv-account-import.c:502:34: error: unknown type name 'GtkObject'
 csv_import_assistant_destroy_cb (GtkObject *object, gpointer user_data)
  ^
assistant-csv-account-import.c: In function 'csv_import_assistant_create':
assistant-csv-account-import.c:597:5: warning: 'gtk_hbox_new' is 
deprecated (declared at 
/usr/include/gtk-3.0/gtk/deprecated/gtkhbox.h:62): Use 'gtk_box_new' 
instead [-Wdeprecated-declarations]

 h_box = gtk_hbox_new(TRUE, 0);
 ^
In file included from /usr/include/glib-2.0/gobject/gobject.h:30:0,
 from /usr/include/glib-2.0/gobject/gbinding.h:31,
 from /usr/include/glib-2.0/glib-object.h:25,
 from /usr/include/glib-2.0/gio/gioenums.h:30,
 from /usr/include/glib-2.0/gio/giotypes.h:30,
 from /usr/include/glib-2.0/gio/gio.h:28,
 from /usr/include/gtk-3.0/gdk/gdkapplaunchcontext.h:28,
 from /usr/include/gtk-3.0/gdk/gdk.h:32,
 from /usr/include/gtk-3.0/gtk/gtk.h:30,
 from assistant-csv-account-import.c:30:
assistant-csv-account-import.c:644:35: error: 
'csv_import_assistant_destroy_cb' undeclared (first use in this function)

   G_CALLBACK (csv_import_assistant_destroy_cb), info);
   ^
/usr/include/glib-2.0/gobject/gsignal.h:475:60: note: in definition of 
macro 'g_signal_connect'
 g_signal_connect_data ((instance), (detailed_signal), (c_handler), 
(data), NULL, (GConnectFlags) 0)

^
assistant-csv-account-import.c:644:23: note: in expansion of macro 
'G_CALLBACK'

   G_CALLBACK (csv_import_assistant_destroy_cb), info);
   ^
assistant-csv-account

Re: configure has difficulty finding libgoffice

[Bob Gustafson]

On 01/19/2014 11:36 AM, Geert Janssens wrote:


On Sunday 19 January 2014 11:16:20 Bob Gustafson wrote:

 On 01/19/2014 01:35 AM, Mike Alexander wrote:

  --On January 19, 2014 1:21:50 AM -0600 Bob Gustafson

  bob...@rcn.com

 And then running autoconf to get a corrected configure script allows

 configure to step over that problem.



Instead of changing the configure script you may want to install the 
devel package for goffice-0.8. I don't think GnuCash has been tested 
with goffice 0.10. So I have no idea if the 0.10 api is compatible.


Yes, that is a much better path. (The goffice-0.10 library caused a lot 
of warnings and errors - deprecated styles, etc.)


I removed the existing goffice

  $ sudo yum remove goffice

And then installed the older version of goffice. There is a slight 
change in the package naming.


  $ sudo yum install goffice08
  $ sudo yum install goffice08-devel

Starting with a virgin copy of the gnucash 2.6.0 source, there were no 
problems with configure, make, or make install.


The result is:

[user1@hoho6 gnucash-2.6.0]$ gnucash --version
GnuCash 2.6.0
This copy was built from rev 38a0d33+ on 2014-01-19.
[user1@hoho6 gnucash-2.6.0]$

Thanks much.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

configure has difficulty finding libgoffice

[Bob Gustafson]

I downloaded the source for gnucash about an hour ago.

I'm running ./configure and this is the end of the output - showing problem:
..
..
checking for gdk-pixbuf-2.0... yes
checking GDK_PIXBUF_CFLAGS... -pthread -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng15 -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include

checking GDK_PIXBUF_LIBS... -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0
checking for libgoffice-0.8 = 0.7.0... no
configure: error: Cannot find libgoffice.= 0.7.0
[user1@hoho6 gnucash-2.6.0]$

If I search for libgoffice, it looks like I have both libgoffice-0.8 and 
libgoffice-0.10


[user1@hoho6 gnucash-2.6.0]$ ls -l /usr/lib64/libgoffice*
lrwxrwxrwx. 1 root root  25 Jan 19 00:33 
/usr/lib64/libgoffice-0.10.so - libgoffice-0.10.so.10.0.9
lrwxrwxrwx. 1 root root  25 Jan 19 00:33 
/usr/lib64/libgoffice-0.10.so.10 - libgoffice-0.10.so.10.0.9
-rwxr-xr-x. 1 root root 1692040 Jan  1 11:15 
/usr/lib64/libgoffice-0.10.so.10.0.9
lrwxrwxrwx. 1 root root  24 Jul  5  2013 
/usr/lib64/libgoffice-0.8.so.8 - libgoffice-0.8.so.8.0.17
-rwxr-xr-x. 1 root root 1376096 Feb 14  2013 
/usr/lib64/libgoffice-0.8.so.8.0.17

[user1@hoho6 gnucash-2.6.0]$

My system is Fedora19

I have gnucash 2.4, which is the latest available through the yum 
install gnucash distribution. I was hoping to be able to use the latest 
and greatest 2.6 series.


Bob G

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Scheme scripting with gnucash.

[Bob Gustafson]

On the Macintosh, many (most?) applications have a script api where they
can be controlled by AppleScript. There is a Required Suite (open, print,
quit, run), a Standard Suite (close, count, exists, ...) and then
specialised suites for each application. The key is that the Required and
Standard suites are the same over many different applications. Cuts down on
learning time. Also once you have a control script working, it is easier to
move it over to another application.

Seems like this might be an interesting proposal for Gnome - an GnuCash
could be one of a group of applications moving toward a common
implementation.

The script language does not have to be guile. It could be perl, ruby,
whatever - as long as the api is accessible in those languages.

BobG


Well, the C re-write is only for the QIF importer.  I do think that
exporting a non-GUI open file API to scheme would be a Good Thing.

-derek

David Bottomley [EMAIL PROTECTED] writes:

 Thanks, anyhow.
 Such a great tool -- I just want a little more from it.
 Maybe Derek's c-re-write is a good option.


 Hi,

 Writing a script like this _should_ be possible.  The only major
 problem that I can think of is the lack of an open file api without
 the associated GUI code, meaning I don't think you can write a script
 that opens a file without also initializing the GUI code.

 The perl bindings fell into disrepair years ago and nobody has been
 willing to maintain them.

 Unfortunately I don't know of any example scripts that would do what
 you want.  Sorry.

 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.809 / Virus Database: 551 - Release Date: 12/9/2004





--
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel