<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sun, Jan 26, 2020 at 5:34 PM Jack <<a href="mailto:ostroffjh@users.sourceforge.net" target="_blank">ostroffjh@users.sourceforge.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p>Dawid,</p></div></blockquote><div>Hello Jack. My apologies for the late reply.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
<p>I use
PAYEEID for Payee, so I didn't expect any changes. </p></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><p>Let me know if
I missed something.</p></div></blockquote><div>Responses below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>I had thought it matched against whichever field you told KMM to use
for Payee.<br></div></blockquote><div> </div><div>Indeed, but unless you're using Online OFX importing, it only allows to match against a single field in its entirety. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>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. </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
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?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>Ouch. And I though I had issues with Merril Lynch. :-)<br></div></blockquote><div><br></div><div>Exactly! Which is why I would like to have an option to combine multiple fields to form a Payee string. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
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. </div></blockquote><div><br></div><div>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". </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>
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.)<br></div></blockquote><div><br></div><div>I'd be happy to discuss this in detail and possibly maybe even have a stab at implementing this. </div><div> </div><div>-- </div><div>Regards,</div><div>Dawid</div></div></div></div></div>