Introduction and timeline for changes
The purpose of this article is to provide the CPO and eMSP managers an overview of the changes being implemented in GreenFlux platform concerning currency definition in prices.
Estimated timeline of changes
- Changes on retail billing rules is live for all tenants and customers since 8/July 11:00 am CEST.
- Changes on wholesale billing rules is live for all platform customers (CPOs) since 10/November.
The changes introduced in both wholesale and retail rules will be backwards compatible and when some validation required from customers, GreenFlux will get in contact with each customer individually.
How did the system behave so far (until currency integrity enhancement is deployed)
We won't go through all the details, but in short it was:
- Wholesale costs: the currency was determined based on the charger's CPO contract where the tariff was assigned.
- Retail costs: the currency was determined per transaction and was based on the wholesale currency. (similar behavior with option 4 in the table further down below).
Introduction to changes - As per new design
A price (e.g. 13.42 EUR) is always composed by 2 parameters:
- an amount (13.42) in the example above).
- a currency (EUR in the example above)
Given our operators may operate across multiple countries (and currencies), it is key to have a clear picture on how currency as a parameter is handled in GreenFlux platform.
Let us recap the EV market value chain and how its modeled through GreenFlux billing engines, to then illustrate the dependences among the different costs and currencies that we have.
As per the value chain, it gets natural that:
- CPO defines a certain cost, so that it covers their costs and they get a certain margin
- eMSP will buy from the CPO and should as such directly or indirectly link the costs they charge to the driver, with the costs they will be charged by the CPO.
As per our platform design, we always provide (in the CDRs) the costs towards the eMSP - wholesale costs - in the currency that the CPO defined for it.
Let us look at a hypothetical example:
- CPO in Norway sets unit price of 5 NOK/kWh. For a session with 10 kWh, the resulting total cost of 50 NOK
- eMSP has a billing rule for this transaction that sets a markup of 10%. In such conditions, the calculated retail cost would amount a total of 55 NOK.
GreenFlux does not support currency conversion in any way in the platform.
Then, when eMSP defines its retail pricing, they can either:
- A) define the retail price dependent on the wholesale price, and as such the currency from retail will be the same as from wholesale.
- B) define the retail price independent from wholesale price, and in this case, they must define explicitly and amount and an associated currency.
Currency definition for retail pricing
There are two parameters that influence the currency definition:
- Wholesale factor: Wholesale Factor (>=0) is a multiplier used to base the retail price on the wholesale price. WSF = 1 means add the exact wholesale cost to the retail cost; WSF = 1.5 means add the wholesale cost plus 50 percent; WSF = 0 means do not use the wholesale cost.
- Tariff code: This parameter is a restriction that can be set to the applicability of the retail billing rule. If Any is selected, then the billing rule may apply to a session containing any tariff code (on wholesale/charger). If a specific tariff is selected, then this retail billing rule can only apply in sessions where the chargers have that specific tariff code.
We have as such the following combination of parameters and their influence on currency definition:
Option 1 and 2* - Currency picked and shown to user based on tariff wholesale currency
*Illustrating example with wholesale factor > 0 (option #2).
In this case, the tariff used is EUR, since this is the tariff associated with tariff code E1. EV Portal will automatically populate the currency field (non-changeable in this option) to EUR.
Example use case: eMSP manager wants to define a cheaper price for their own drivers in charging infrastructure they won and operate, containing tariff code E1.
Option 3 - Currency must be defined by the user
In this case, user must select a currency that will be associated to the calculated cost.
Example use case: eMSP manager wants to define a standard AC price in Germany, and they will want that price to be in EUR.
Option 4 - Currency is unknown upfront and will be defined for every transaction, based on the currency provided by CPO (Wholesale currency)
In this case, the currency that will be set for the calculated costs will be in the same currency as the wholesale costs, and the retail cost amount will be 110 % of the wholesale costs. User is not able to change anything in the currency field in this case.
Example use case: The eMSP does not want to bear any financial risk, and as such add 10% margin on top of wholesale costs.
If eMSP wants to invoice their driver always in the same currency, they must make sure to handle the currency conversion on their end, since hypothetically and under this option 3, their drivers could charge in Norway, Germany and UK, and as such would receive retail currency in NOK, EUR and GBP, respectively.
Currency definition for wholesale pricing (and reimbursement pricing)
In this case, it is substantially simpler. Each (wholesale) tariff has a currency associated. This is then the currency that applies to wholesale and reimbursement costs (if applicable).
As follows an example on the tariff creation flow of how one sets-up the currency for a given tariff:
