Reps' phones showed the wrong currency and dates

Your sales rep opens the app in a customer’s shop. The prices are in the wrong currency, or the dates are a day out. The office looks at the same order and cannot see what is wrong, because on their screen it is fine.

The cost is quiet. A rep reading figures in the wrong currency has no reason to doubt them. It is worse offline: the app opens, shows yesterday’s orders from its saved copy, and formats them wrongly, which is more misleading than showing nothing.

When we counted, across the two apps (the office portal and the phone app) there were roughly a hundred and twenty places where the language, the timezone or the currency had been written straight into the code. English. Coordinated universal time. One currency code, repeated on every screen that showed money.

What was actually going on

The reflex is to call that sloppiness and ask for a tidy-up. The tidy-up would have come straight back, because every one of those fixed values was a developer solving the same real problem: at the moment that screen draws, the app does not know the right value.

It did not know because the company’s language, timezone and default currency lived on a settings record, and reading that record needed an administrator’s permission. A field sales rep does not have it and should not. So a rep’s phone had no legitimate way to find out which currency its own prices were quoted in.

Every fixed value was a workaround for a permission drawn in the wrong place.

What we changed

We separated two kinds of settings that had been treated as one. Administrative ones, such as seat limits, which modules are switched on, the tax regime and the financial year start, are properly restricted. A rep has no business seeing the seat limit. Display ones, the language, the timezone and the currency, are needed by every signed-in user on every screen, and they already appear on any invoice that user may see.

The three display values now travel on the call every app already makes straight after sign-in, to learn who the user is and what they may do. It cost nothing measurable, because the values sit on a record that call already loads.

One person can belong to several companies and chooses which to work in after signing in. In between, there is a valid session with no company, so no company currency. The obvious move is to return sensible defaults there. We return nothing, deliberately, and the apps fall back to the device’s own settings. A default from the server looks authoritative, and an app will format money with it. A guessed currency is a lie that looks like data.

On the phone, the three values are saved with the session, not with the ordinary saved responses. A cold start with no signal restores both together, so every screen formats correctly before a single request succeeds. Twenty-six screens on the phone app had their fixed values deleted in that pass, and the formatting helpers now need no extra information from the screen, because a helper that has to be told the locale will eventually be told the wrong one.

What it did not fix

Removing a wrong default exposes everything that was quietly relying on it, and that made two defects the change nearly introduced.

Due dates, issue dates and expected close dates are calendar days, not moments. Run through a timezone-aware formatter, they would shift by a day in either direction, so they needed a separate formatter with no offset. And a task list that grouped jobs into overdue and due-today had been working them out against the universal calendar, not the company’s. That was uniformly slightly wrong before, and obviously inconsistent with the dates beside it afterwards, which is how it got noticed.

Both were caught during the work, not after. But it is an uncomfortable kind of fix: the screens look worse for a moment because they stop agreeing with a wrong answer.

Until somebody chooses a company, the currency is the device’s guess, not the company’s. That is honest, but it is not the company’s own figure.

The pattern, for anyone running a sales app

Find every screen that shows money or a date, and ask where it learns the currency and the timezone. If the honest answer is “it is fixed in the code”, the app is one overseas customer away from showing someone the wrong figure.

Then ask who is allowed to read the company’s settings. If the settings that decide how a number is shown are locked behind the same permission as the settings that decide what a user may do, you have guaranteed that somebody will guess.

Where this ends up

Sazinga Field is the field-sales system this came from, where a rep takes orders on a phone in a customer’s shop. The language, timezone and currency reach that phone with the session, so what the rep reads is what the company set.