You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When downloading statements from a FI, I'd like to be able to create *.ofx files importable by GnuCash, compatible with the OFX files that banks' interactive websites offer.
I find that when I call FinancialInstitutionAccount.readStatement() and marshal that out to a file, that file is not usable by GnuCash. (Didn't test with Quicken or anything else.) Such files have <CCSTMTRS/> as the root element.
It turns out that if I marshal out the whole, ResponseEnvelope, that works with GnuCash. Such files have <OFX/> as the root element.
However I can't seem to find an clever way to gain access to the ResponseEnvelope that's currently just a local variable in BaseAccountImpl.readStatement().
The only way I've found, is to change interface FinancialInstitutionAccount, adding a new method readStatementResponseEnvelope(). In BaseAccountImpl, readStatementResponseEnvelope() is a clone of readStatement(), but which returns the ResponseEnvelope instead of the statement.
It doesn't seem possible for my project to subclass BaseAccountImpl to provide readStatementResponseEnvelope(), because I don't see a way of injecting my custom BaseAccountImpl into the stack.
I don't know if it's worth finding general way for the caller to access ResponseEnvelopes or this is the only practical use case for having access to them. If the latter, then the first approach that comes to mind would be to just factor readStatement() into (public) separate readStatementResponseEnvelope() and readStatement(), with the latter invoking the former. Doesn't seem elegant though.
Thoughts?
The text was updated successfully, but these errors were encountered:
Can I get a better idea of your goals? If you're just trying to construct an ofx file from Java objects, I think the idea is that you construct a com.webcohesion.ofx4j.domain.data.ResponseEnvelope and set the appropriate properties. I can't figure out where readStatement is coming into play in your use case. Are you just trying to read statements and create OFX files?
My goal is to use OFX4J to connect to a bank (e.g. Citibank), download transaction data for a certain range, and serialize that out to a local file. Then I want to use the "Import" feature of GnuCash to import the transactions from the file. (Yes this basically reproduces GnuCash's own built-in ability.)
I'd like to create local files that are compatible with the files that the banks allow users to download from the banks' websites. The trouble is that I can't seem to do so unless I serialize out the ResponseEnvelope -- which OFX4J doesn't provide ready access to.
When downloading statements from a FI, I'd like to be able to create
*.ofx
files importable by GnuCash, compatible with the OFX files that banks' interactive websites offer.I find that when I call
FinancialInstitutionAccount.readStatement()
and marshal that out to a file, that file is not usable by GnuCash. (Didn't test with Quicken or anything else.) Such files have<CCSTMTRS/>
as the root element.It turns out that if I marshal out the whole,
ResponseEnvelope
, that works with GnuCash. Such files have<OFX/>
as the root element.However I can't seem to find an clever way to gain access to the
ResponseEnvelope
that's currently just a local variable inBaseAccountImpl.readStatement()
.The only way I've found, is to change
interface FinancialInstitutionAccount
, adding a new methodreadStatementResponseEnvelope()
. InBaseAccountImpl
,readStatementResponseEnvelope()
is a clone ofreadStatement()
, but which returns theResponseEnvelope
instead of the statement.It doesn't seem possible for my project to subclass
BaseAccountImpl
to providereadStatementResponseEnvelope()
, because I don't see a way of injecting my customBaseAccountImpl
into the stack.I don't know if it's worth finding general way for the caller to access
ResponseEnvelope
s or this is the only practical use case for having access to them. If the latter, then the first approach that comes to mind would be to just factorreadStatement()
into (public) separatereadStatementResponseEnvelope()
andreadStatement()
, with the latter invoking the former. Doesn't seem elegant though.Thoughts?
The text was updated successfully, but these errors were encountered: