<div dir="ltr">Hi all,<br><br>I'm building a small Python tool that imports bank OFX/QFX transactions by<br>parsing the file in Python and writing the transactions through the official<br>GnuCash Python bindings. To behave like the GnuCash app GUI importer, I need two things it gets from libofx:<div><br>1. Per-transaction de-duplication: set/read each imported split's **`online_id`**<br>   (the OFX **FITID**) so re-imported or overlapping statements don't create<br>   duplicates.<br>2. Account mapping: read/write an account's **`online_id`** (the bank<br>   identifier) so I know which GnuCash account a statement belongs to.<br><br>From reading the source, both values already live in the engine as a plain KVP<br>slot (`"online_id"`) on Split/Account/Transaction — the same slot the OFX and<br>HBCI importers use. But it isn't reachable the way I'd expect: the only C<br>accessors are the `gnc_import_*_online_id` helpers over in the import-export<br>module, and nothing is exposed to the Python bindings (the bindings only wrap<br>functions declared in the public Split/Account/Transaction headers).<br><br>The approach I'd like to propose is to promote `online_id` to **first-class<br>engine accessors**, alongside an object's other identity data — e.g.<br> - `xaccSplitGetOnlineID`<br> - `xaccSplitSetOnlineID`<br> - `xaccAccountGetOnlineID`<br> - `xaccAccountSetOnlineID`<br> - `xaccTransactionGetOnlineID` <br> - `xaccTrannsactionSetOnlineID`  (no practical use currently)<br> <br>There's no new logic — the KVP get/set already exists<br>internally; this just makes it public. A nice side effect is that the Python<br>binding then comes essentially for free through the existing auto-wrapper<br>(`Split.GetOnlineID()`, etc.), with no SWIG interface changes.<br><br>The change is purely additive — same KVP slot, no behaviour or data change — and I've left the existing import-export helpers untouched (they could delegate to the<br>new accessors later if you'd like a single source of truth).<br><br>I have a branch with the accessors, C round-trip + KVP-parity tests, and Python<br>binding tests, all passing locally (native build and a from-source container<br>build with the SQL backend):<br><a href="https://github.com/Noerr/gnucash/tree/online-id-engine-accessors">https://github.com/Noerr/gnucash/tree/online-id-engine-accessors</a><br><br>Before I open a PR I wanted to check: does promoting `online_id` to the public engine API sound like an agreeable direction?<br><br>Happy to adjust. Thanks for all your work on GnuCash.<br><br>Best,<br>Noah<br></div></div>