The setup
One of the accountants comes up and asks if I could help her out. She has a number of foreign currency transactions she needs to input, but the exchange rate dictionary in the database doesn't have data for the dates she needs - she's working on past periods, probably prior to the accounting database being set up for the client.
Step 1: Try the obvious
"Have you run the updater?"
For an extra fee, the software provider offers the service of providing exchange rate updates - it's a service we subscribe to, naturally. Yes, she has tried it and no - it didn't work.
Step 2: Try the fancy management software
The accounting package we use can be centrally managed with a separate program that performs bulk operations on many databases (each client has a separate DB). One of the operations involves updating the exchange rate dictionaries. I do it - does not solve the problem.
Step 3: Consult the internet
"Maybe we're doing something wrong..." I think.
I pull up the official website and am informed that the exchange rate update mechanism only provides rates for 30 days prior. The sole support forum for the software does not offer any user-discovered workarounds either.
I had been hoping that the central management mechanism I mentioned in step 2 would perform a bulk update from a source DB to the target DB, but it turns I was overly optimistic. There is no way to automatically update exchange rates older than 30 days.
Step 4: What if we throw SQL at the problem?
"Fine," I think, "if that's the way you want to play it, I'll just dump the data from where I have it to where I need it."
I pull up the schema for the exchange rate table and, wouldn't you know it, identity fields are for wimps. Sure, the table has a bog-standard, incrementing integer id field - except, it is not actually specified as an identity. The software only runs on SQL Server, by the way. At this point, I could develop a data transfer solution that would integrate the import without breaking anything (which would be an excellent opportunity to find out how their update mechanism dervies its PK values; and just how braindead the solution is) - or I could shrug and say that manual input is the way to go.
Bonus
It is pretty much an immutable principle here in Poland that whenever you're dealing with a foreign currency transaction, the amount should be recorded in PLN, at the rate published by the National Bank of Poland for the working day directly preceeding the date of the transaction (the NBP doesn't publish rates for non-working days, incidentally). This requirement is specified in both income tax (PIT and CIT) Acts, the VAT Act and anywhere else you damn well please. It's been like this forever and shall remain so in the foreseeable future.
Guess what date our accounting software takes the rates for? The date of the transaction, of course! Why on Earth would it do anything different? And no - you cannot set it up to act otherwise.
In trying to solve my immediate problem, I came across this issue being raised on the aforementioned support forum - five years ago. Apparently, the company was going to fix it in one of the upcoming updates, but eventually decided not to, because it turned out to be too hard to implement.
Seems that "WHERE ExchangeRateDate < TransactionDate" was too difficult. Sure, some checks for missing data would be in order here, but even without them the software would perform as expected 90% of the time (and you're meant to perform manual sanity checks anyway; that's what accountants get paid for). To make matters even funnier, the software also does HR and payroll and therefore the DB has calendars with all weekends and holidays built in - whether the actual HR module is enabled or not.
I am left wondering if it's a case of them having really crappy developers, or was it simply that they couldn't be arsed. Either way, the way their software handles exchange rates continues to be wrong, five years on.