At CarbonEES we strive to ensure that e-Bench is a modern, user-friendly, secure and bug-free software experience. But as with any software occasionally a bug slips through. When someone finds and reports a bug we target a one working day resolution. As we understand that e-Bench often provides critical reporting data we know how important it is that you are confident in the reports that e-Bench produces. For that reason we document any bug that could possible affect the outputs that a user has derived from e-Bench. These are listed below
Date Reported: Fri 15 Nov, 2024
Date Resolved: Fri 15 Nov, 2024
Description: When graphing scope 3 emissions, carbon (invoiced) view outputs were clearly divergent from energy (usage) view outputs. Furthermore organisation-wide values were significantly less than the emissions from just one constituent data source
Analysis: Within the reporting engine there is a switch that is used to determine what subset of organisational data sources should be used for any given reporting request. This method had not been correctly updated to include the “invoiced” or carbon view variants of reporting request. As such an energy view scope 3 request would correctly use the “co2” subset of data sources but a carbon view scope 3 request would instead (incorrectly) use the “energy” subset of data sources.
Resolution: “invoiced” variants added to the switch determining which subset to use.
Date Reported: Thu 14 Nov, 2024.
Date Resolved: Thu 14 Nov, 2024.
Description: When creating a graph is the reporting year is changed (eg from calendar year to financial year) while a series is loading, that series does not receive the updated parameter and will display against the wrong month labels. For example the axis would show Jul – Jun of a financial year but the actual data will be for Jan – Dec of a calendar year.
Analysis: The graphs are built using a population function which scans through all the requested series, determines if we already hold data, have already requested data, or have not yet requested data. It then requests data for any series for which no data has been requested. When the reporting year is changed all data is cleared. The function is then called, detects that we don’t hold data and requests the updated data from the server. However the data request is not being cleared. Thus if a reporting year is changed while the series is still loading, the population function sees an active request in place and doesn’t bother to request new data for this series. Furthermore the reporting year of provided data was not being checked against the current state of the graph, so this data was allowed to show when it arrived.
Resolution: Both held data and data requests are cleared when the reporting year is changed. The population function now correctly sees that an action is required on that series and requests the new data. On receipt of data from the server, the reporting year is checked against the current reporting year. If it does not match (ie the request is from before the reporting year was changed), this data is dropped instead of being displayed.