That description doesn't imply "permanent" to me. All it implies is unique. It seems perfectly logical for a given transaction to be able to have multiple unique IDs, or even transient unique IDs. As long as no two different transactions ever get the same unique ID, then you're good from a uniqueness point-of-view.
That's certainly not what seems like the most practical or convenient way to do it, but still, uniqueness does not imply permanence.
But the whole point of that field is to prevent the creation of duplicate transactions -- something that requires both uniqueness *and* permanence.
11:23 PM
While working on some bank import engines for Expensify I found I was getting duplicates. Naturally I assumed I was screwing things up, but despite a full sweep through the code I couldn't find any bugs. The only theory I could come up with was the <FITID> attribute was changing on a given transaction. But that's impossible, right? From the OFX spec: "3.2.3 Financial Institution Transaction ID <FITID>
An FI (or its Service Provider) assigns an <FITID> to uniquely identify a financial transaction that can appear in an account statement. Its primary purpose is to allow a client to detect duplicate responses. Open Financial Exchange intends <FITID> for use in statement download applications, where every transaction (not just those that are client-originated or server-originated) requires a unique ID." Yep, sounds pretty permanent to me. Except it's not. In fact, it's quite common for the FITID to change, at least for US Bank . I'm guessing it changes as the state of the transaction changes -- only the last two digits appear to change.
Anyway, this is probably just a random bug with US Bank, right? Not according to this forum.
Ugg. What a pain. How hard is it to just follow the rules and make a truly unique identifier?
"OFX FITIDs: Not as permanent as you might think"
2 Comments -
That description doesn't imply "permanent" to me. All it implies is unique. It seems perfectly logical for a given transaction to be able to have multiple unique IDs, or even transient unique IDs. As long as no two different transactions ever get the same unique ID, then you're good from a uniqueness point-of-view.
That's certainly not what seems like the most practical or convenient way to do it, but still, uniqueness does not imply permanence.
9:35 PM
But the whole point of that field is to prevent the creation of duplicate transactions -- something that requires both uniqueness *and* permanence.
11:23 PM