...
What do we already know? | If someone sells or rents out a recreational accommodation, it is mandatory to propose an energy label to the buyer / renter and mention this in any advertisements. From 1-1-2024 onwards the Dutch organ ILT will inspect if legislation is complied with. Exceptions are possible, no energylabel is required for i) monuments, ii) detached units with <50m2 usable area, iii) >2 years not in use, iv) units without energy installations and v) units with <4 months usage per year and <25% energy usage compared to a full-year usage scenario. Energylabels must be registered at the online government portal EP-online. This results in a registration number which might be relevant to add in MXTS. Energylabel is at unit level Legislation allows holiday resorts to efficiently label comparable units with same characteristics (based on maps). In other words, units belonging to the same accommdationtype are most likely evaluated and processed in bulk. It refers to Dutch legislation, so this does not apply to units in countries other than NL. The due date of energy labels is 10 years.
|
|---|
What do we need to answer? | How does the evaluation process and its output look in practice? In other words, what does our client receive from evaluators and in which format? Should the obligation to mention energylabels in advertisements be interpreted as mandatory to display on client websites? Can it be expected the energylabel is used for reports / batch update processes etcetera? (Manage prices for units with Energylabel X for instance, or as search criteria on a website) Is it relevant to keep track of energylabel changes other than via the unit_history_log? Is it correct understood (based on Infographic) only label A-G are valid for recreational units? (And A+/A+++++ are only for residential/utility)
|
...
What are we doing? | Store energylabel at unitlevel as amenity in potentially a new amenity_category to reflect the unit energylabel Store energylabel_reference at unit level to have a mapping between MXTS units and EP-Online units (Potentially) Store amenity at accommodationtype level to display the relevant information at websitelevel (which often has a bookingfunnel at accommodationtype level) (Potentially) store PDF documents at unit level (either Rentable unit or Owner unit, depends on customer preference) Make sure PDF documents are exposed via API Make sure PDF documents can be displayed on CMS and MCMS owner portal Make sure the unit energylabel can be displayed on email templates which are send to guests Make sure user can have insight in energylabel configuration; which units have and which units do not have an energy label
|
|---|
Why will a customer want this? | It is mandatory legislation in NL to have the energylabels for recreational units. Multiple clients are also convinced it is mandatory to display the energylabel during the booking process |
Visualize the solution | Somewhere at unit level a varchar field should be available to add the energylabel reference_code (there seems enough space to add a field). Registrationnumber is a 9 digit numeric code, but let’s make the field flexible enough (varchar 15 digit for instance)  Either the rentable_unit or owner_unit will have the PDF document stored which should be exposed (via API) at owner portals  |
Scale and scope | Project size is SMALL |
...
Government portal for registration by client
Example energylabel
| View file |
|---|
| name | verzamelbrief-over-energielabel (1).pdf |
|---|
|
| View file |
|---|
| name | infographic-vernieuwd-energielabel-woningen-en-gebouwen-nta-8800 (1).pdf |
|---|
|
...