-
Feature
-
Resolution: Done
-
Normal
-
None
-
None
-
-
COST-1320Understand the costs of running applications in OpenShift
-
0% To Do, 0% In Progress, 100% Done
Feature Overview
Cost management should be capable of using currencies in price lists and gather information from different sources using different currencies and show them together in the same interface.
Goals
Currently we don't support currencies in the product but any account in an international environment that is multicurrency will need some kind of currency management.
- Allowing the customer to add accounts in different currencies and see all the information together.
- Making it possible to define currencies for price lists
- Make it visible the source currency and the account currencies so the customer can see the original data (that is matched to the data in the sources) and the cost management data (that is using the account currency)
Requirements
Requirements | Notes | Is MVP? |
---|---|---|
There MUST be a way of selecting the currency in the account. | Use ISO list for currencies | yes |
There must be a way of exchanging currencies to the account currency. | Yes | |
There must be a way of visualizing the data with the currency | base currency and value, and exchange currency and value | No |
There SHOULD be a way of importing data in different currencies and keep the exchange rates up to date | No |
Use Cases
Out of scope
- Per user currency definition (to show showback data in local currency), we need only to support account currency
- Others To be defined. historical treatment of data (understand the exchange rate used in former time), and manual management of exchange rates could be left out of scope.
Background, and strategic fit
One of the requirements from accounts using financial data is to reflect the fact that purchases are done in the local currency.
In AWS, that means that children accounts can have a different currency than the parent account, and thus makes it really hard to compare costs from one account to the other.
For cost management, that can be more complicated once we start delivering showback/chargeback information
Why is this important
This requirement is important as many of our customers are not using dollar as their currency, or they are using more than one currency (i.e. most of the international enterprises).
Use Cases
- The customer defines the account as EURO, all information is shown in the interface in EUR, but can be found in the original currency and EUR
- The customer defines the price list as EURO, all the information is shown in EUR
- The customer defines the price list as $, all the information is shown in EUR, but can be found in $ and EUR
- When selecting a currency, most used currencies (EUR and $) are shown first, although it is possible to add other
- Rate exchange is based on the current exchange rate, stored once a day from a know exchange rate service. Information is always stored in the original currency and converted.
h2 Questions to answer...
How will the user interact with this feature?
Throughout the interface, every cost will be shown in the account currency, with the possibility to show the original currency and the exchange rate used to show the cost shown.
Which users will use this and when will they use it?
All users can use this feature, although it will be frequent on non-US and multi-currency customers. As AWS provides prices in $, it will be necessary the moment we support any currency in the user interface that is not $.
Is this feature used as part of the current user interface?
There are some pieces already visible in the interface
Out of Scope
- Currency exchange for customer defined exchange rates (i.e. the customer defining the rate for time periods, like defining that the exchange rate to be used is 1.1122$/€ in the period Jan 1st to June 31st and then defining a different price from July 1st to December 31st)
- Showing and storing exchange rate information in the reports.
- is blocked by
-
COST-230 Design Spike: Currency Support
- Closed