Navigation:  Module 1 - Energy Accounting > Accounts & Invoices Tab >

User Defined Components

Previous page Next page
  rev. 2011-07-28        

User-Defined Components are either fixed values or formulas which interact with Meter Readings and other User-Defined Components to create interim invoice calculations and the Final Total.




Component Name


The main identifier for the component.  Must be unique within  the Tariff.

Reading Group


Leave this blank to stipulate that this is a User-Defined Component and not a Meter Reading

Type (Reading Type)


Always set automatically to User-Defined.



Can be set to a currency unit (such as $ or £), or left blank.  Appears on data entry screens, dashboards, reports, and exports, but does not affect calculations.

Constant Value or Formula


This is the definition of the component, either a constant or formula.



A brief description of the component.  Will also be displayed as the tool tip when the mouse pointer hovers over this field on the billing data entry form.

Invoice Total


Every Tariff definition must have exactly one User-Defined Component identified as the Invoice Total.  The Invoice Total is needed to report on utility costing and to import invoice data electronically.

Formula components are calculations based on other components.  Interim calculations, subtotals and the Invoice Total are all formula components.

In theory, a single user-defined formula component could be used to translate the Meter Readings into the Final Total for any invoice.  In practice, users often want to verify sub-calculations that appear on invoices.  The best and simplest approach is to define formula components matching line items on the invoices.


                                    For most utility accounts, constant values will not change from one  invoice to the next.  However ManagingEnergy does allow alternate constant values to be specified at the time of invoice entry.  This feature is required when variable market-based pricing is in effect; i.e. where the unit cost for the commodity is unpredictable and is constantly changing.  Default c0nstant values can be changed regardless of the means of invoice entry, whether manual or electronic.

Users with many facilities and accounts, and where invoice entry is manual, may find it convenient to adjust constant values within the tariff definitions each month prior to invoice data entry.  This would  avoid having to make adjustments on each invoice.

Component Formulas

ManagingEnergy utility tariffs are user-programmable to account for the wide variety or rate structures that exist.  The user creates custom expressions within User-Defined Components to perform calculations at the time of invoice entry.

Defining a formula component is much like defining a formula in a spreadsheet cell.  It's a small piece of computer programming.  As with any computer programming, you need to know the language.

Tariff components are written in Python, a common object-oriented scripting language.



                                    Python Programming Language

Expressions are written using the Python dynamic programming language, supported by Microsoft and the broader open-source community.  The ManagingEnergy tariff implementation differs from standard Python  in two notable ways:

1.We have added a number of special-purpose object structures and functions to make the job of defining User-Defined Components as easy as possible.  These are described in Object Types and Functions.
2.Component Names and Reading Group names in a formula must be enclosed in [square brackets].

The Python language reference is available at  ManagingEnergy users will only ever use a small fraction of the language set.


A Few Basic Rules

All functions and variable names are case-sensitive.
All component names and Reading Group names within a formula must be enclosed in square brackets [ and ].  For example the component named  ConsNG would appear in a formula as [ConsNG].
Global variables, which are pre-defined within the system, must not have square brackets.
Component names and Reading Group names can contain spaces or underscore characters, but must not contain special characters like % or $ or .
Date and time manipulation is common within utility tariffs (e.g. a unit cost changes after a certain date; consumption percentages are allocated to time-of-day bins).  Date and time related components have to be defined with precision.  The tariff engine will not try to interpret text strings.  ManagingEnergy has several purpose-built date and time object types and functions to make the job as straightforward as possible.



                                                              Convention for Date Ranges

Where a time span is expressed as a period between two dates, it is always understood to extend from midnight starting the first day to midnight starting the last day.  The start date of the period is fully included and the end date is fully excluded.  For example, a span covering the month of March 2010 would be expressed as March 1 to April 1.  Written as a DateRange object, it would be 3/01/2010 12:00:00 AM - 4/01/2010 12:00:00 AM


                                                             The details of this process will make much more sense to someone experienced in object-oriented programming.  If you have someone like that in your organization, half an hour reviewing this documentation together will save you a lot of time.

The following pages provide a reference for defining formulas.  Read this section carefully and spend some time reviewing existing Tariff definitions before starting work on your own.  If you get stuck, contact the Help Desk for support.


snippet_Tariffs-User_Defined_Component         ©2014 Managing Energy Inc.