We have internal business requirements where we need to view revenue and accounts receivable in different currencies for the purpose of collaborating and reporting to outside parties. We need to see our reporting in one currency and then flick a switch to immediately see those same figures in a different currency, accurately converted based on the currency rates for the dates the transactions occurred.
It’s all set up and working like a charm. It enables the accurate changing of all figures into different currencies based on the changing of a single field.
The way I’ve achieved this is to create a separate “Set Base” database with a single entity in it which has just a single select field showing the different currency options. When I change that drop down field everything else changes to reflect that change, including reporting.
It all works really well.
The reason I’m posting here is that it intuitively feels like an odd database design to have an entire database for the purpose of housing a single entity with a single drop down box to make such a change.
I don’t know of any other way to achieve this.
It’s not a problem as it works perfectly, but I am just curious whether there is a better, best practice way of achieving this.
It’s quite possible I’m not offering enough information, but we basically set the currency on the contact level. One contact can have many payments and each of those payments can be dynamically converted using the conversion rate at the date the payment was made, into different currencies based on the setting in the single select field on that single entity in the “Set Base” database I referred to above.
I understand exactly what you mean about using a DB to store what is effectively a global single select (well, I hope I understood what you meant!)
I don’t actually think there is a better way of doing it at the moment, and perhaps it’s just the psychological unease that’s the issue.
I could imagine that in the (probably quite distant!) future there might be ‘nicer’ ways of doing it, for example using some clever polymorphism functionality, whereby a (hidden?) database of such ‘global variables’ could exist, and each variable could be related to (=> available for use by) multiple other dbs, and each variable would be linked to one of many of possible ‘value’ collections.
Can’t see it happening any time soon though!
This is one of those things that will be a subtle but very real barrier to broader adoption IMO (emphasis mine, of course). This kind of thing needs a better solution IMO.
What about the sort of ad-hoc fields we’ve discussed at various times? Would that work? Like a unique field that is attached to a single entity or doc or whatever?
@Oshyan it would be nice if next to “Add database” there could be “Add global variable” and that could be used in formula calculations and exposed in a view for the values to be changed.
There I go again, talking solutions rather than problems and use cases! Oops.
To be fair, I am not aware of many no-code tools that have native support for global variables (Coda? others?) so I would hope that this is not a barrier to adoption for a lot of people.
That is fair, but also a great place for Fibery to differentiate. But I’d agree it’s not a showstopper by any means. And clearly there is too much to do at the moment in any case.
But I’d agree it’s not a showstopper by any means. And clearly there is too much to do at the moment in any case. 