Bug #271
closed
Transaction discards all but the first line of the purpose
Added by jralls@ceridwen.us over 3 years ago.
Updated 2 months ago.
Betriebssystem:
Linux, MacOSX, Windows
Version der Anwendung:
3.8 and later
Description
With an MT940 record element
:86:1017?61SAMMELGUTSCHRIFT FÜR KONTO: CH2909000000250094239 VERARBEI
TUNG VOM 17.06.2020 PAKET ID: 9999999999999999
AB_TransactionGetPurposeAsList() returns a GWEN_STRINGLIST of length 1 containing "7?61SAMMELGUTSCHRIFT FÜR KONTO: CH2909000000250094239 VERARBEI". The second line is lost.
I've traced this to AB_Transaction_ReadDb where
/* member "purpose" */
if (p_struct->purpose) {
free(p_struct->purpose); p_struct->purpose=NULL;
p_struct->purpose=NULL;
}
{ const char *s; s=GWEN_DB_GetCharValue(p_db, "purpose", 0, NULL); if (s) p_struct->purpose=strdup(s); }
sets the value to only the first stored line in the db and
GWEN_STRINGLIST *AB_Transaction_GetPurposeAsStringList(const AB_TRANSACTION *t)
{
const char *s;
assert(t);
s=AB_Transaction_GetPurpose(t);
if (s && *s)
{
GWEN_STRINGLIST *stringList;
stringList=GWEN_StringList_fromString(s, "\n", 0);
return stringList;
}
return NULL;
}
Where AB_Transaction_GetPurposeAsStringList tries to split it into multiple lines on newlines. The catch is that Swift940.c's _parseTransactionData already did that and stored the results in the database in multiple strings.
I'm not able to find where AB_Transaction_ReadDb is implemented in transaction.xml
See https://bugs.gnucash.org/show_bug.cgi?id=797565
- Status changed from New to Resolved
Hi,
in function AHB_SWIFT940_Parse_86(https://www.aquamaniac.de/rdm/projects/aqbanking/repository/revisions/master/entry/src/libs/plugins/parsers/swift/swift940_86.c) there are calls to _transformPurposeIntoOneString() which transforms the list of purpose strings into a single string before the transaction reaches AqBanking.
That call was in the code for structured :86: fields but missing for unstructured ones. I added that missing call 19 days ago and therefore it is already in AqBanking 6.5.3. So I consider this bug fixed unless reported otherwise.
BTW: transaction.xml gets translated into source files (transaction.{c,h}) which contain getters, setters as well as functions to read/write to/from GWEN_DB objects, XML objects and others using GWEN's typemaker2 tool. This is done by the packager before creating the release tarball if needed (or on the fly when using gwbuild).
Since transaction.{c,h} are generated files they are not in our GIT repository.
Regards
Martin
I wonder if you might have gone too far. The whole transaction record is
:61:2006180618C1500,FMSC6536086135//07582000303F0C7U
202006180005000303F0C7U000000000
:86:1017?61SAMMELGUTSCHRIFT FÜR KONTO: CH2909000000250094239 VERARBEI
TUNG VOM 17.06.2020 PAKET ID: 9999999999999999
and purpose is
202006180005000303F0C7U000000000 1017?61SAMMELGUTSCHRIFT FÜR KONTO: CH2909000000250094239 VERARBEI TUNG VOM 17.06.2020 PAKET ID: 9999999999999999
Is it supposed to pick up the extra line from the :61: tag?
- Status changed from Resolved to Feedback
I believe I asked you about what should be done with the extra data in the :61: field because in the test data you provided me a few weeks ago (I think in a Gnucash bug entry) that line was the only source of information about the transaction while the :86: field was nearly empty.
That's why I introduced the profile setting "readExtraData61" which is set to yes in the profile "SWIFT-MT940" (but not in the profile we use for HBCI in "fints940" because we don't have that extra data here AFAIK).
I wonder about the format of this data here: It seems like they tried to make it structured but never pulled through: They seem to be using a four digit code in the beginning of the :86: field and then use half-baked subfield numbers (introduced by "?"). Where is that file from?
Martin,
Sorry, I'm not sure where that example came from save that it's a somewhat random one from a website that I found last month while I was looking for examples to test with. From the header info
{1:F01POFICHB0AXXX0000000000}{2:I940XXXXXXXXXXXXN}{3:{108:SWIFT00010366395}}{4:
:20:SWIFT00010366395
:25:CH2909000000250094239
:28C:118/1
:60F:C200618CHF211993,19
it appears to be a swiss bank from 2 years ago.
The time stamp is 29 July so it's from before our email conversation about making a description field and your mention of a Swiss example file for the :NS: field handling.
Yes, they do appear to be using some sort of formatting that no doubt makes sense to their software.
I don't recall discussing the purpose field or extra :61: data with you before or even knowing that :61: might have extra data.
Ah, so peripheral I completely dumped it. And the response was "As for the supplemental data, heck if I know." That's still true.
The spec says what the SWIFT folks think it should be for--either to replace the customer reference if that's NONREF, to facilitate reconciliation, for something called ERI, or to provide an exchange rate for multi-currency transactions. The instant case seems to repeat the transaction date and the last 10 characters of subfield 8. That doesn't seem to me to support any of those purposes, but that's just that one instance from a possibly mythical bank. For all I know other banks put useful information in that field.
"If not that info what goes into AB_Transaction_GetTransactionText and AB_Transaction_GetPurposeAsStringList?" was a question, not a suggestion. I now know that TransactionText comes only from :NS:17 tags and I've found at least some of the places in MT940 that get used to create Purpose.
I guess it's one more component of that "what pieces do you want where" dialog box from https://bugs.gnucash.org/show_bug.cgi?id=797877, though it would have to be added to the file import code too, not just HBCI/FinTS online transaction retrieval. This is probably heading down the "more trouble than it's worth" path.
- Status changed from Feedback to Closed
No feedback for a long time, closing. Please reopen if still relevant.
Also available in: Atom
PDF