Yeah, and perhaps I wasn't following your advice of:
It actually requires make uninstall && make clean && make && make install to
ensure that the changed code is used.
> On Mar 18, 2020, at 5:32 PM, John Ralls wrote:
>
> Chris,
>
> I guess in your case it was having OFXHEADER:100 and
Chris,
I guess in your case it was having OFXHEADER:100 and VERSION:102. I think
that's all that changed between your last failed run and the successful one.
Regards,
John Ralls
> On Mar 18, 2020, at 5:21 PM, Chris Graves wrote:
>
> John,
>
> You are probably right, but here is an excerpt
Thanks Adrien..
On Thu, 19 Mar. 2020, 08:29 Adrien Monteleone, <
adrien.montele...@lusfiber.net> wrote:
> If they find info is missing or they don’t care for the formats, report
> back here and we’ll try to help you refine them.
>
> Regards,
> Adrien
>
> > On Mar 18, 2020 w12d78, at 6:01 PM,
John,
You are probably right, but here is an excerpt from the working ofx.log
file, so I guess I'm not sure what enabled this progress:
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
That did it!
Now to that crash.
Regards,
John Ralls
> On Mar 18, 2020, at 5:06 PM, Martin Preuss wrote:
>
> So the only remaining difference is the line "bankid" which wasn't in
> the aqb5 log.
>
> Just applied a change to the git repository to change that...
>
>
> Regards
> Martin
>
>
>
If they find info is missing or they don’t care for the formats, report back
here and we’ll try to help you refine them.
Regards,
Adrien
> On Mar 18, 2020 w12d78, at 6:01 PM, Adrian Yong
> wrote:
>
> Thank you very much, Adrien, Michael and Stephen for helping me understand
> Gnucash...
>
>
First, please always copy the list on all replies - others may benefit from the
discussion or lend better advice.
-
As for using a Check vs. a Credit Card for payment, there’s no difference
between them.
Say you make a purchase at a store for bottled water and batteries with cash,
Chris,
You have it backwards: Martin changed LANG -> LANGUAGE because that's what AQB5
used.
However, I just tested on a bank account at USAA and that worked, except that
it crashed GnuCash when trying to process the new transactions. That's probably
not AQBanking's doing and I'll look into
So the only remaining difference is the line "bankid" which wasn't in
the aqb5 log.
Just applied a change to the git repository to change that...
Regards
Martin
Am 19.03.20 um 00:53 schrieb John Ralls:
> Nope:
> Connected.
> Sending message...
> Message sent.
> Waiting for response...
>
I changed aqb6 to use "LANGUAGE" like aqb5 did, because that is the
correct name (don't know where I read "LANG", I guess that was in
another protocol...)
According to the specs (1.6) "LANGUAGE" should be used.
Regards
Martin
Am 19.03.20 um 00:57 schrieb Chris Graves:
> John,
>
> In your
John,
In your ofx.log file it still says LANGUAGE instead of LANG. Mine says
LANG, which is what Martin just fixed.
On Wed, Mar 18, 2020 at 4:54 PM John Ralls wrote:
> Progress indeed, though still not enough for USAA. :-(
>
> Regards,
> John Ralls
>
>
> > On Mar 18, 2020, at 4:48 PM, Chris
Okay, we should now look for console logs.
I'm not sure how Gnucash handles log files, but you could try the
process of requesting statements using console-only:
1. get list of accounts:
# aqbanking-cli listaccounts
Column 6 contains the unique account id to be used in the next step.
2. get
Interesting, there were 8 Sending requests and 3 Received responses. Looks
like transactions were returned duplicated 3 times.
On Wed, Mar 18, 2020 at 4:46 PM Martin Preuss wrote:
>
> the OFX specs show this example:
>
> -X8
> POST
Progress indeed, though still not enough for USAA. :-(
Regards,
John Ralls
> On Mar 18, 2020, at 4:48 PM, Chris Graves wrote:
>
> Wow! making serious progress now. I was requesting transactions from my
> checking account. Looking at the ofx.log file, they were returned!!!
>
> However the
Nope:
Connected.
Sending message...
Message sent.
Waiting for response...
Receiving response...
HTTP-Status: 400 (Bad Request)
Unlocking customer "8"
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
Wow! making serious progress now. I was requesting transactions from my
checking account. Looking at the ofx.log file, they were returned!!!
However the import process indicated that there were no transactions to be
imported.
On Wed, Mar 18, 2020 at 4:32 PM Martin Preuss wrote:
> Hi,
>
> I
the OFX specs show this example:
-X8
POST http://www.fi.com/ofx.cgi HTTP/1.0
User-Agent:MyApp 5.0
Content-Type: application/x-ofx
Content-Length: 1032
OFXHEADER:100
DATA:OFXSGML
VERSION:160
SECURITY:TYPE1
ENCODING:USASCII
CHARSET:NONE
I did
--- a/src/libs/plugins/backends/aqofxconnect/v1/r_statements.c
+++ b/src/libs/plugins/backends/aqofxconnect/v1/r_statements.c
@@ -77,7 +77,7 @@ int AO_V1_RequestStatements(AB_PROVIDER *pro, AB_USER *u,
AB_ACCOUNT *a, AB_TRAN
}
GWEN_XMLNode_free(xmlRoot);
-#if 0
+#if 1
Hi,
I just checked in another change... While comparing your logs I found
that aqb6 uses "LANG" while aqb5 used the correct name "LANGUAGE".
Also, added "CLTCOOKIE" (was set by aqb5 but missing in aqb6).
Also, I noticed that aqb5 included "BANKID" which you log from aqb6
didn't contain that
That's what mine says:
char flags="forceSsl3", "sendShortDate"
char bankName="USAA Federal Savings Bank"
char org="USAA"
char fid="24591"
char serverAddr="https%3A%2F%2Fservice2.usaa.com%2Fofx%2FOFXServlet"
char appId="QWIN"
char appVer="2300"
char headerVer="102"
Thank you very much, Adrien, Michael and Stephen for helping me understand
Gnucash...
I will submit the documents as suggested by Stephen and see what the
auditors say... They are CPAs...
On Thu, 19 Mar. 2020, 06:37 Michael or Penny Novack, <
stepbystepf...@comcast.net> wrote:
> On
On 3/18/2020 1:52 PM, Stephen M. Butler wrote:
Adrian,
I give my CPA three items:
1. Balance Sheet.
2. Profit Loss statement
3. Transaction Report of all transactions for the year sorted by
account and then by date within account.
That last is the "general ledger" (when for all
Sigh, that's not it either:
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20200318151247.000
Hi,
hmm, so no linebreaks...
Could either of you please try with the following lines commented out in
v1/n_toofx.c:
- 105: if (hasSubTags)
- 106: GWEN_Buffer_AppendString(buf, "\r\n");
- 128: GWEN_Buffer_AppendString(buf, "\r\n");
Will be back in a few mins, have to watch an episode of
Is there any easy way to capture the dialog between the client and server?
> On Mar 18, 2020, at 3:04 PM, John Ralls wrote:
>
> The only difference I see now in the ofx.logs is the newlines, and I still
> haven't figured out if they're correctly escaped in the http request.
>
> Regards,
>
The only difference I see now in the ofx.logs is the newlines, and I still
haven't figured out if they're correctly escaped in the http request.
Regards,
John Ralls
> On Mar 18, 2020, at 2:59 PM, Martin Preuss wrote:
>
> Hi again,
>
> with the latest changes: Are there any probably
Remember, the working ofx from AQB5 is
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20200315112517.000
20200315112517
It actually requires make uninstall && make clean && make && make install to
ensure that the changed code is used.
Regards,
John Ralls
> On Mar 18, 2020, at 2:52 PM, Martin Preuss wrote:
>
> Hi,
>
> okay now, the latest GIT version always sets "OFXHEADER:100" and uses
> the given header
Not sure if it matters, but the OFX clause/aggregate? in AQB5 is on three lines
with a line break after the USERID and again after USERPASS.
In git, there is a linebreak after each element/aggregate.
> On Mar 18, 2020, at 2:51 PM, John Ralls wrote:
>
> I changed the line just below OFXHEADER
Hi again,
with the latest changes: Are there any probably important differences in
the generated OFX request compared to Aqb5's output (except dates etc.)?
Regards
Martin
Am 18.03.20 um 22:50 schrieb Chris Graves:
> Hi Martin,
>
> The GUI wouldn't let me leave that field blank, so I manually
Hi,
please see my other mail (latest GIT).
Maybe "103" then (I heard of some cases where "103" was necessary)? Or
perhaps "160"?
Will fix the gui btw...
Regards
Martin
Am 18.03.20 um 22:50 schrieb Chris Graves:
> Hi Martin,
>
> The GUI wouldn't let me leave that field blank, so I manually
Hi,
okay now, the latest GIT version always sets "OFXHEADER:100" and uses
the given header version only for the "VERSION:" header. In that case
you can specify "102" and it should create the correct headers...
Please note: For reasons not yet understood it might be necessary when
updating from
I changed the line just below OFXHEADER to
GWEN_Buffer_AppendString(buf, "100");
producing the following. No luck, it still returns a 400 error.
Regards,
John Ralls
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
Hi Martin,
The GUI wouldn't let me leave that field blank, so I manually deleted the
entry from the .conf file. Running again, it did use the defaults that you
specified. However, still the http 400 error and no response.
Sending:
-
OFXHEADER:100
DATA:OFXSGML
It won't let you leave that blank, and even if it did it would put '100' in
both fields:
if (!(s && *s))
s="100";
GWEN_Buffer_AppendString(buf, "OFXHEADER:");
GWEN_Buffer_AppendString(buf, s);
GWEN_Buffer_AppendString(buf, "\r\nDATA:OFXSGML\r\n");
GWEN_Buffer_AppendString(buf,
Hi,
not ATM, but that can be arranged. However, how about leaving that field
empty in the settings dialog? That should default to 100 for OFXHEADER
and 102 for VERSION (for - ahem - historic reasons, I'm sure I had
good^H^H^H reasons for those mixed defaults... :-})
Regards
Martin
Am 18.03.20
Nice! I see that the change has been made, but still receive the HTTP 400
error.
In the AQB5 ofx.log file for a successful case, I see
OFXHEADER:100
VERSION:102
In the AQB6 file, I see
OFXHEADER:102
VERSION:102
Not sure if this could be the problem. Is there a way to set OFXHEADER and
VERSION
Hi,
you can change the header manually to 102/103 in the homebanking setup
dialog (select user, edit user, switch to app settings and type-in
header version 102).
Regards
Martin
Am 18.03.20 um 21:57 schrieb Chris Graves:
> Hi Martin,
>
> Looking better! However, to my knowledge, my bank only
I think that would have been a mistake, git defaults to OFXv1.
> On Mar 18, 2020, at 1:38 PM, Christopher Singley wrote:
>
> See the top post on this thread - John Ralls reporting that git only speaks
> OFXv2. However many banks only speak OFXv1.
>
> I can confirm that I can download from
Hi Martin,
Looking better! However, to my knowledge, my bank only supports OFX
version 102 or 103. I had been using 102.
ofx.log:
Sending:
-
OFXHEADER:220
DATA:OFXSGML
VERSION:220
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
See the top post on this thread - John Ralls reporting that git only
speaks OFXv2. However many banks only speak OFXv1.
I can confirm that I can download from USAA by speaking OFXv1.0.2.
I can no longer speak OFXv2 to USAA; something has changed on their side.
Sorry John, no workaround yet.
Hello Michael,
Am 18.03.20 um 17:37 schrieb Michael L. Wilson:
> Greetings,
>
> Might someone be able to confirm whether GnuCash is able to issue
> invoices in line with the European electronic invoicing standard?
1. GnuCash has, at least until now, no eInvoice ability.
2. There is no B2B
Hi Chris,
could you please test the latest GIT version? It should create valid
OFXv1 requests now, however, I can't test it completely since I only
have access to an OFXv2 server...
Regards
Martin
Am 18.03.20 um 16:31 schrieb chris graves:
> An additional bit of information from /tmp/ofx.log:
Here is what I was thinking were significant differences found in ofx.log.
AQB5 vs git, which should be defaulting to OFX 1.
AQB5:
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
But I'm using (or trying to use) OFX V1.
> On Mar 18, 2020, at 1:23 PM, John Ralls wrote:
>
> That would be because they are XML syntax. OFX V2 is XML.
>
> Regards,
> John Ralls
>
>
>> On Mar 18, 2020, at 1:15 PM, chris graves wrote:
>>
>> Because I don't see them in the AQB5 ofx.log file
That would be because they are XML syntax. OFX V2 is XML.
Regards,
John Ralls
> On Mar 18, 2020, at 1:15 PM, chris graves wrote:
>
> Because I don't see them in the AQB5 ofx.log file and to me they look like
> XML syntax. Not being knowledgeable on the subject I can't say for sure. I
>
Because I don't see them in the AQB5 ofx.log file and to me they look like XML
syntax. Not being knowledgeable on the subject I can't say for sure. I
thought at v1.6, the syntax was pure SMGL. But again, I don't know what I
don't know.
> On Mar 18, 2020, at 1:12 PM, John Ralls wrote:
>
>
Don't worry about that. That's a standard OFXv2 header (i.e. compliant
XML). The other headers you were noting earlier are OFXv1 headers (i.e.
the weird INI-formatted key: value pairs prepended to the SGML soup).
The problem I have is that USAA bank tells me it will speak OFXv2, and
then
And why were you thinking that?
Regards,
John Ralls
> On Mar 18, 2020, at 1:05 PM, chris graves wrote:
>
> I was thinking that it could be the first two lines of your file below.
>
>> On Mar 18, 2020, at 12:40 PM, John Ralls wrote:
>>
>>
>>
>>> On Mar 18, 2020, at 9:33 AM, Christopher
Are you able to make OFX connection with USAA's server in any manner
whatsoever?
I have a dormant USAA bank account that I used to be able to download,
that now is returning HTTP 400 for the same OFX configs that used to
work. They haven't moved the server, have they?
(ofxtools) 11:39:27
> On Mar 18, 2020, at 10:18 AM, Alan Auerbach wrote:
>
> Dear John,
>
> I am using Win10 Pro. If I go back to gnucash 3.6, will I lose valuable
> updates in exchange for OFX Direct Connect? It seems to be a choice or wait
> and see if it is working in the next update.
Depends. If you're in
I was thinking that it could be the first two lines of your file below.
> On Mar 18, 2020, at 12:40 PM, John Ralls wrote:
>
>
>
>> On Mar 18, 2020, at 9:33 AM, Christopher Singley wrote:
>>
>> You're sending VERSION="220", which USAA doesn't accept. You need to send
>> VERSION="200" or
> On Mar 18, 2020, at 9:33 AM, Christopher Singley wrote:
>
> You're sending VERSION="220", which USAA doesn't accept. You need to send
> VERSION="200" or VERSION="202". Try that.
No joy, I still get a 400 response, but it does occur to me that it isn't
necessarily an OFX issue, it could
On 3/17/20 8:50 PM, Adrian Yong wrote:
> Hi Adrien,
>
> Thanks for your very detailed explanation...
>
> I appreciate that we enter each transaction using the double entry system
> into the accounts.. This is almost the same as manual accounting.
>
> The problem arises when the auditors do not use
I didn’t think either Firefox or LibreOffice were GTK. I thought each had its
own toolkit.
GIMP is GTK (it was originally the GIMP Tool Kit) as is Gedit. (among others
belonging to the Gnome desktop suite) Maybe try installing something like those
and seeing what the scrollbars do.
Regards,
Sorry, I sent too fast and read too slowly.
If the arrows only appear on the main window when a dialog has focus, but not
when the main window has focus, that would seem backwards to me.
You might have a bug there. (which might still be part of a GTK on Plasma
conflict)
Regards,
Adrien
> On
The full screen / off full screen makes no difference. The character in
the scroll bar up/down buttons is missing.
So far I've now looked at three GTK3 based applications - gnucash,
libreoffice and firefox.
For all three applications, I can alter the width of the scrollbar by
editing the
Again, sounds like a preference in Plasma, though perhaps a design choice of
Plasma, or even GTK.
I’m surprised you still have the scroll bar at all if that window doesn’t have
focus.
There may not be an easy solution if that behavior is by design without an
exposed preference to change it.
Okay, that looks like the basic requirement is an XML document that conforms to
UBL (Universal Business Language) with some country specific additional
requirements. (those would have to be investigated and addressed individually)
GnuCash doesn’t provide this out of the box, but it might be
Dear John,
I am using Win10 Pro. If I go back to gnucash 3.6, will I lose valuable
updates in exchange for OFX Direct Connect? It seems to be a choice or wait
and see if it is working in the next update.
Best wishes,
/s/ Alan
14343 North Frank Lloyd Wright Boulevard, Apt. 1009
Scottsdale, AZ
Apologies, might not have explained it very well.
The arrows < > do appear on the vertical scrollbar of the main window,
but only when a dialog has the main focus. When the dialog is closed the
arrows disappear and will only reappear if another dialog is opened.
Your "proper solution" is
Hello!
I think the following might be useful:
https://docs.microsoft.com/en-us/dynamics365/finance/localizations/emea-oioubl-standards-electronic-invoicing
M
On 3/18/20 6:55 PM, Adrien Monteleone wrote:
> I don’t see anything there about actual requirements. It appears to be just
> about the
I don’t see anything there about actual requirements. It appears to be just
about the process of coming up with a standard. I did look over the ‘directive’
and still it was short on final specs.
Do you have a link for whatever was eventually settled on?
Regards,
Adrien
> On Mar 18, 2020
Is your main window set to full screen?
If so, do the buttons appear properly when you take it off full screen?
A quick work around might be to size the window to fill the screen but not use
the full-screen setting. Then you know where to look for a setting or report a
bug to either GTK or
Sounds like a Plasma preference, though I find it curious it is visible on
dialogs but not the main window.
The proper solution probably involves resolving a display problem with GTK on
Plasma, but you might be able to fake it with the `::before` pseudo element and
some creative positioning to
Greetings,
Might someone be able to confirm whether GnuCash is able to issue
invoices in line with the European electronic invoicing standard?
https://ec.europa.eu/growth/single-market/public-procurement/digital/einvoicing_en
If any documentation exists concerning this, it would be greatly
#1, 2, are available in GnuCash and easy enough to produce.
#3 would be done as an ‘Account Report’ while viewing the General Journal.
Recall though that you’ll have to adjust the View > Filter By to show the
desired dates before running the report.
#4 can be accomplished as I previously noted
You're sending VERSION="220", which USAA doesn't accept. You need to
send VERSION="200" or VERSION="202". Try that.
On 3/18/20 11:31 AM, John Ralls wrote:
Interesting. USAA can't parse the OFXv2 that AQBanking 6.1.2 emits.
Unfortunately it just returns an HTTP 400 response, no details.
Interesting. USAA can't parse the OFXv2 that AQBanking 6.1.2 emits.
Unfortunately it just returns an HTTP 400 response, no details. Perhaps like v1
there are Intuit-induced quirks in the v2 parser as well and we'd need to
capture a v2 interaction with Quicken to figure them out.
Regards,
John
Thanks. Just, y'know, keep it cool on the profile scanning... each one
spams a lot of requests.
Your bank's server has an OK parser... standards-compliant OFXv1.0.3
(what Quicken sends). Sadly no OFXv2 support.
On 3/18/20 10:50 AM, Chris Graves wrote:
ofxtools -- nice toolset!
Here are
ofxtools -- nice toolset!
Here are the results from my bank:
ofxget scan kinecta
[{"versions": [102, 103], "formats": [{"pretty": false, "unclosedelements":
false}, {"pretty": false, "unclosedelements": true}, {"pretty": true,
"unclosedelements": false}, {"pretty": true, "unclosedelements":
An additional bit of information from /tmp/ofx.log:
AQB5:
Sending:
-
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:20200318081757.000
...
git:
Sending:
Hi everyone
My system is
Slackware Current
KDE5 Plasma
with
gtk+3 3.24.14
linux 5.4.25
gnucash 3.8
I have a config file .config/gtk-3.0/gtk.css which contains the folllowing
@import 'colors.css';
scrollbar {
-GtkScrollbar-has-backward-stepper: true;
On 3/18/2020 1:59 AM, Adrian Yong wrote:
Thank you very much for your assistance.
I submit the following to the auditors:
1) P
2) Balance Sheet
3) Journal
4) General Ledger
5) Funds(Cash) Flow Statement
6) Trial Balance
That's because they don't use QuickBooks...
Regards,
Adrian
All of
> Aside from the extra whitespace, which shouldn't matter, the git code has
closing tags on every element while the AQB5 code has closing tags only on
grouping elements.
>
> USERID is specified in the OFX 1.6 DTD as
>
> and according to
>
> On 18 Mar 2020, at 03:00, David Carlson wrote:
>
> I added gnucash-user to the cc to distribute this to wider audience.
>
> I believe that if you export to pdf, then some pdf readers do split between
> lines. I think Firefox is one that works ok, but it has been a while since
> I tried it.
>
Thank you very much for your assistance.
I submit the following to the auditors:
1) P
2) Balance Sheet
3) Journal
4) General Ledger
5) Funds(Cash) Flow Statement
6) Trial Balance
That's because they don't use QuickBooks...
Regards,
Adrian
On Wed, 18 Mar. 2020, 13:21 Adrien Monteleone, <
77 matches
Mail list logo
