Determining Use/Day and/or Cost/Day would be easy in a perfect w= orld where every utility received one and only one utility bill for each co= mmodity in each accounting period. In real life, the situation is complicat= ed by various approaches to accounting, handling of rebills, refunds, corre= cted bills, etc.

Over time, EnergyCAP has devised and recommended various best practices = to minimize the difficulties, which center around how the software counts (= or doesn=E2=80=99t count) the days associated with each bill received for d= isplay and reporting purposes.

This topic explains the current logic as it will be ported over from Ene= rgyCAP 3.6 to our next generation HTML-based software.

**NOTE:** References to BAM =3D Bill Account Meter table in=
the EnergyCAP database

Affects:

- Use/Day column
- Cost/Day column

Overlapping bills and multi-account meters will NOT inflate the number o= f days since you are always dealing with only ONE bill

Front-end - bill list column displays what is given to it.

Back-end =E2=80=93 the list API calculates "days" as BAM.endDate - BAM.b= eginDate, usePerDay as nativeUse / days, costPerDay as directCost / days

Affects:

- Building Groups > Cost > Cost/Day
- Building Groups > Use > Energy use/Day

Overlapping bills and multi-account meters will inflate the number of da= ys, resulting in smaller benchmarking numbers. Also, incomplete data may ca= use numbers to shift.

Front-end - displays what is given to it; the per-day benchmark value is= obtained directly from the API

Back-end - Place group digest relies on data contained in BAM, with day = values. Unlike the meter digest, this appears to use a simple SUM(days) to = get the number of days in a period. The "n/day" values are then calculated = by calculating value/days (e.g. totalCost / daySum). The max of the day cou= nts is returned in the data transfer object (DTO); should be 365, but may h= ide meters which have less than 365 days, making it hard to reconcile by ha= nd using just the data in the DTO.

Affects:

- Meter Groups > Cost > Cost/Day
- Meter Groups > Use > Average Use/Day

Overlapping bills and multi-account meters will NOT inflate the number o= f days, resulting in larger and "more correct" benchmarking values. However= , incomplete data may deflate numbers.

Front-end - displays what is given to it; the per-day benchmark val= ue is obtained directly from the API

Back-end - Meter group digest relies on data contained in BAM, with day = values. The "days" calculation is MAX(endDate) - MIN(beginDate). The "n/day= " values are then calculated by calculating value/days (e.g. totalCost / da= ySum).

Affects:

- Meter > Actual Data > Summary > Daily Average Cost
- Meter > Actual Data > Summary > Daily Average Use
- Meter > Normalized Data > Summary > Daily Average Use
- Place > Actual Data > Summary > Daily Average Cost
- Place > Actual Data > Commodity > Daily Average Cost
- Place > Actual Data > Commodity > Daily Average Use
- Place > Normalized Data > Summary > Daily Average Use

Overlapping bills and multi-account meters will NOT inflate the number o= f days, since it's a static 365. However, incomplete data may deflate numbe= rs.

Front-end - All up/down charts work the same way; chartHelper.getArrowCh= artData() - divide this year/last year totals by 365 days ("annualized")

Back-end - Place digest relies on data contained in staging tables (e.g.= BillSummaryPlaceCommodityRollupCP) which DO NOT contain "per day" values..= . all the staging table views calculate "simple" per day values on the fron= t-end.

Affects:

- Meter > Actual Data > Trends > Use/Cost Per Day Trend
- Meter > Calendarized Data > Trends > Use/Cost Per Day Trend

Overlapping bills and multi-account meters will NOT inflate the number o= f days, resulting in "more correct" trend values. Incomplete data will caus= e missing points on the chart.

Front-end - chartMeterUseCostPerDayTrend.execute() contains the logic. T= he cost, use and number of days from the API as calculated in the back-end = are divided out (e.g. totalCost / days =3D cost/day)

Back-end - Meter digest relies on data contained in BillAccountMeter whi= ch DOES contain "per day" values. SQL for the "days" value is calculated by= taking the MAX(BAM.endDate) - MIN(BAM.startDate).

The logic for counting days in the Reports module in EnergyCAP is more s= traightforward, and relies on two days-related calculations:

- The difference between the MIN(beginDate) and the MAX(endDate)
- SUM(days).

MIN/MAX looks at the spectrum of bills included in the report and simply= counts the days between the earliest billing period BEGIN DATE and the lat= est billing period END DATE, not counting the END DATE.

This method works well unless there is a gap in the billing data. In tha= t case, the MIN/MAX value would be larger than the period(s) represented by= the included bills. In this (unlikely) scenario, the sum of the days for t= he included bills will be used, but only if that value is smaller than the = MIN/MAX value.