Which rate, whose date, and which way round it is stored — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for whoever fills in the Currency Rate box, or signs off the figures that come out of it. In about twelve minutes you will know what that one number is used for, and how to prove which way round yours is stored before it costs you a month.

Step 1 — Find out where your rate came from

After this step you will know which of three things filled that box. If the Forex Data Source selector is switched on for the applet, choosing a source copies the newest rate recorded for that currency pair — the newest one, not the one for the document’s date. If the source has no rates recorded, the box stays at zero. If the selector is off, somebody typed the rate or pressed Refresh and took a live market quote. Purchase documents take the recorded sell rate and sales documents take the buy rate, so the same pair on the same day gives two different numbers depending on which way the goods are going.

Reference: Forex Applet

Step 2 — Notice that the rate has no date of its own

After this step you will stop assuming the rate matches the document. The selector always takes the most recently dated row for the pair and copies it in. Nothing compares that row’s date with the document’s transaction date. So a bill you key on the twelfth, dated the second, gets the twelfth’s rate unless somebody overwrites it — and a back-dated document keyed at month end gets month end’s rate. If that matters to you, record the rate for the day before you key the documents for that day, or type the rate on the document. There is no setting that makes the selector date-aware.

Step 3 — Meet the column with two readers that disagree

After this step you will understand the single hardest thing about foreign currency here. One column on the document holds the rate, and two different parts of the platform read it in opposite directions. The twin is built by dividing every amount by it — which only gives the right ringgit figure if the number is expressed as foreign units for one ringgit. But the printed invoice, the e-invoice sent to the tax authority and the accounting export all pass the same column through as the direct rate, the familiar four-point-something ringgit per dollar. Both readers are in the shipping product. A backend comment names the conflict in as many words.

Reference: Forex Applet

Step 4 — See how the product itself works around it

After this step the workaround will tell you how real the problem is. One path into the system, the invoice file import, deals with it explicitly: it reads an application setting that says, for this currency, whether the incoming rate needs inverting, flips it if so, finalises the document so the twin is built from the flipped value, and then writes the original rate back onto the document so the printed copy still shows what the customer sent. That is three deliberate steps to keep two readers happy. Nothing equivalent happens when a person keys a document on a screen: whatever is in the box is what the twin is built from.

Step 5 — Run the thirty-second test

After this step you will know which direction your tenant is on. Raise one small foreign-currency document, finalise it, and find its twin. If the twin’s total is the sensible ringgit equivalent, your rates are stored the way the twin needs them. If the twin’s total is far too small when the foreign currency is the stronger one, the rate is stored the other way round, and the twin is wrong by the square of the rate — at four point one to the dollar, that is a factor of about seventeen. Across all ninety of BigLedger’s tenant databases both directions are in live use, in comparable numbers, so neither answer is unusual.

Step 6 — Do the right thing with the answer

After this step you will not make it worse. If your twins are right, record the direction somewhere your team can find it and keep entering rates the same way. If they are wrong, do not start hand-editing rates on documents: every twin, every journal and every realised exchange difference already built from them is wrong by the same factor, and changing the rate on a document that is already finalised does not rebuild anything. Raise it with your BigLedger contact as a tenant-level question about rate direction. And in either case, watch for the zero rate — a foreign-currency document with no rate is refused at Finalise, and the message says so plainly.

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Where the exchange difference lands when you knock the invoice off · Back to the series · Play this as a presentation