Retroactive error correction
Retroactive changes to agreement start and end dates may only be made in clear cases of error. As a rule of thumb, retroactive corrections should follow this principle: balance information is determined based on the supplier that made the error, while agreement information is determined based on the party entitled to invoice the customer. The underlying principle is that the supplier responsible for the error is accountable for the balance sheet, even if they do not have the right to invoice the customer.
The supplier reports the retroactive start of a sales agreement using the same notification used to report an upcoming sales agreement (DH-311). The report of a new retroactive sales agreement progresses like a normal process if there are no other suppliers’ agreements valid for the accounting point after the date on which the reported sales agreement begins. In other cases, a sales agreement that begins retrospectively will not progress as a normal process and instead Datahub locks the process and responds with negative confirmation to the notification of a sales agreement which is to begin retrospectively. In order for the processing of the sales agreement to continue, the reporting supplier must manually process the data in Datahub’s interface.
The supplier must provide an explanation in the interface as to why the agreement should begin retroactively and submit the processor’s contact details for clarification. After this, Datahub will notify the current supplier of the new supplier’s explanation and contact details by e-mail and create a retroactive start approval request for the current supplier in Datahub’s interface. The current supplier must approve the retroactive start in the interface in order for processing of the retroactive sales agreement to continue.
If the current supplier approves the retroactive start, the agreement process continues as usual. Upon rejection by the current supplier, negative confirmation will be sent to the new supplier that reported the retroactive agreement. If the current supplier neither approves nor rejects the retroactive start, Datahub will send a reminder to the current supplier after 2 business days and, if necessary, the Datahub operator will contact the current supplier directly. After a retroactive sales agreement has been approved, the agreement and balance data for an accounting point are determined based on the new supplier’s notification as shown in the figure below.
If between the start date of an agreement that begins retroactively and the time of reporting there are valid sales agreements from more than one different supplier, the aforementioned procedure cannot be applied. In this case, the Datahub operator will investigate the details of all parties and guide them in resolving the matter amongst themselves. After the parties have come to a decision on a solution, the Datahub operator will make the necessary changes in Datahub.
The following diagram presents the process for handling retroactive new sales agreements.
Retroactive terminations of agreements are primarily done as a part of retroactive new agreement notifications, when the reported new agreement automatically ends the previous sales agreement. Market parties cannot separately report retroactive agreement endings (DH-330 events) except in case of meter removal. If a retroactive agreement ending is needed because of an error situation, the market party must contact the Datahub operator, who can end an agreement retroactively. The operator processes performed by the market operator are described in section The market operator’s correction processes.
In addition to the aforementioned cases, there may be situations in which there is a need to retroactively change the start or end dates of a previously reported agreement. The principles mentioned above are to be followed in these situations. The start and end dates of agreements cannot be changed using an agreement data update event in Datahub. Instead, the earlier notification must always be cancelled first, whereupon a new notification should be sent with a corrected date. If the current supplier has previously notified Datahub of the agreement ending, this end date can be corrected by reporting a new end date with a new agreement end event. In that case, the previous agreement end date must be replaced by the end date of the new notification.
The aforementioned correction procedures should only be used in cases of error. Retroactive changes are monitored, and possible misuse will not be tolerated. If the situation requires an accounting point’s balance data to be recorded in a manner other than that specified above, the market party or market parties must contact the Datahub operator, which will make the necessary changes based on a written request. If the new sales agreement is reported retroactively to Datahub in error cases, Datahub will not automatically forward the metering data for that retroactive period. The supplier who has reported the sales agreement gets the metering data from Datahub using a metering data request event.