This section is intended to providegeneral best practice guidelines for the use of flexible pricing from a business perspective. These guidelines are intended to supplement the technical functionalityby providing details on how to treat edge case scenarios thatcould occur in the above use casesfrom a business perspective.
A. Guidelines for creating flexible pricing Service Offers on the HBS Portal
1. When creating a service offer for Authorization, the “Flexible/Dynamic” option should be selected as pricing model whenever more than one tariff/price value is applicable. When more than one price value exists for the offer, the OICP PricingProductDataRecords structure should be used to capture the pricing details either as:
- a csv file that needs to be attached to the service offer through an upload (as described on the following page: https://support.hubject.com/hc/en-us/articles/115000150945-Create-a-New-Service-Offer
- as a JSON object that can be sent per web service to the HBS using the eRoamingPushPricingProductData operation (see the OICP 2.2 document for details)
Essentially, the PricingProductDataRecords to be defined can have one of the following structures:
a) Multiple base prices (e.g. different base prices for different time periods or different locations/EVSEs)
b) Single base price with additional variable components to be referenced in determining the final applicable price (e.g. a single base price for consumed energy plus an additional fee for parking or a start fee for process initiation, etc.)
c) Multiple base prices with additional variable components to be referenced in determining the final applicable price (e.g. any combination of the examples given above in (a) and (b) )
Note: the base price is the price value to be provided in the field "PricePerReferenceUnit" for any specific ProductID. So,any one ProductID always corresponds to one base price.
2. The following restrictions apply whenever the “Flexible/Dynamic” pricing option is assigned to a service offer:
- The PricingProductData attached to the offer cannot be updated after the first subscription to the offer is created by an EMP. Specifically, this means new pricing ProductIDs can neither be added to nor deleted from the offer.
-
For location/EVSE-specific pricing, EVSEPricingdata containing only new EVSEIDs can be added to the data set on the HBS even after the first EMP subscription. However, if the new EVSEID is assigned to a new ProductID that was not included in the original PricingProductData upload, the upload will be rejected and no update will be performed by the HBS.
Note: it is recommended that partners desist from the old practice of selecting the “Standard” pricing option and subsequently adding pricing details(showing multiple tariffs) in a pdf attachment. The “Standard” pricing option is to be selected only if the offer has a single price value for the single selected reference unit (e.g.10 EUR per hour, or per kWh, or per minute)in all scenarios.
B. Guidelines for handling potential edge casesin the billing process
1. For each charging session, it should be possible to assign one and only one pricing ProductID that is to be used for the billing process. It is also highly recommended that this ProductID is included in the respective CDR(using the field PartnerProductID in the CDR) in order to increase transparency and efficiency in determining which tariff/price is to be applied in billing the charging session.Note: CPOs that use the Hubject Intercharge Billing service MUST always include a ProductID in their CDRs.
2. For time-based flexible pricing, if the complete duration of the charging session results in an overlap of two or more pricing products/tariffs (i.e. 2 ProductIDs), the ProductID valid at ChargingStart time is applicable for the billing process.For instance,in the scenario depicted below, the “MorningTariff” ProductID shall be applicable for billing the charging process for EV-1 whereas the “AfternoonTariff” ProductID shall be applicable in the case of EV-2:
3. The field “AdditionalReference” in the OICP PricingProductDataRecordsstructure provides the following additional price references which can be used to define a variable component to be considered in addition to the base price:
a. Start Fee
b. Fixed Fee
c. Parking Fee
d. Minimum Fee
e. Maximum Fee
In using these additional price references, the following guidelines are to be observed:
a. Start Fee: can be used in case a fixed price is charged for the initiation of the charging session. The price value provided here is to be added on top of the base price value defined for the ProductID in question.
b. Fixed Fee: can be used if a single fixed price is to be billed irrespective of charging duration or energy consumption (e.g. when all sessions are to be charged a single fixed fee). When used, the base price value for the respective ProductID should be set to zero and in the billing process, the price value provided as fixed fee will be the single value billed for all sessions.
c. Parking Fee: can be used in case sessions are to be billed for both parking and charging. When used, the default definition shall be that the Parking Fee applies from SessionStart to SessionEnd.
Note: in future updates of the OICP, we intend to provide the possibility for CPOs to determine when parking starts and when it ends based on different combinations of the SessionStart, ChargingStart, SessionEnd, and ChargingEnd attributes.This means,a CPO can for instance choose to define their parking fee as being applicable from ChargingEnd to SessionEnd rather than the above SessionStart to SessionEnddefinition.
d. Minimum Fee: can be used in case there is a minimum fee to be paid for all charging sessions. When used, this implies that the final amount to be paid cannot be less than (but can however be greater than) the minimum fee.See exhibit below:
e. Maximum Fee: can be used in case there is a maximum fee to be paid for all charging sessions. When used, this implies that the final amount to be paid cannot be more than (but can however be less than) the maximum fee. See exhibit below:
