OFX importer should not ignore non-empty Name field if Payee or Memo are empty (patch provided)

[Dawid Wrobel]

On Sun, Jan 26, 2020 at 5:34 PM Jack <ostroffjh at users.sourceforge.net>
wrote:

> Dawid,
>
Hello Jack. My apologies for the late reply.

> I use PAYEEID for Payee, so I didn't expect any changes.
>
Indeed, you wouldn't see any changes unless any transaction had an empty
MEMO and a non-empty NAME, in which case the latter would be used instead.
The original code would simply duplicate the PAYEE instead.

> Let me know if I missed something.
>
Responses below.


> I had thought it matched against whichever field you told KMM to use for
> Payee.
>

Indeed, but unless you're using Online OFX importing, it only allows to
match against a single field in its entirety.

Then, depending on the match, user should be allowed to decide which of the
> matches is to be used for which field. A similar option exists now in OFX
> Direct Connect plugin, but it is limited to Payee and Memo matching only.
>
> Ah - this is what I'm using, so it's why I though the above.  However, I
> don't think I've noticed any different behavior when importing an OFX
> file.  Do I need to test better?
>

You would have to try to import an OFX file by hand, because the patch I
sent is for the code used only during the manual import. It would be even
better if you tested with more than one statement, each with different
fields used to store Payee – e.g. NAME and PAYEEID, preferably with some
empty MEMOs.


> Ouch.  And I though I had issues with Merril Lynch. :-)
>

Exactly! Which is why I would like to have an option to combine multiple
fields to form a Payee string.

> I'll have to leave that to Thomas, but my need still sounds a bit
> orthogonal, and is just that if the Payee used for the imported transaction
> is found by matching (anything other then being exactly the same as
> whatever imported field is used) the keep the original field as part of the
> memo, so as not to lose the actual original payee.
>

I do understand and find it a serious limitation of the Payee mathiching,
but in my proposed solution, this problem would be solved by the ability
"to store the original key:value metadata for future inspection".

You'll have to discuss the code with Thomas, but I take care of the manual,
> so that's actually easy for me to update at the same time as the code.  (I
> know there are still outstanding edits to bring the manual fully up to date
> with current 5.0.x release.)
>

I'd be happy to discuss this in detail and possibly maybe even have a stab
at implementing this.

-- 
Regards,
Dawid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20200204/5f9c8350/attachment-0001.html>