Navigation:  Carbon Consumption > Consumption Master >

Capture Consumption Data

Training Manuals Alphabetical Function List Back Print this Topic Previous topicOne level upNext topic

This is the main operational function in the carbon consumption functionality. It records all consumption data per category, location (building), unit of measure (DOL code – denomination of life), type of action (measure/ weigh etc.), measurement type (supplier actual, average, meter reading or guesstimate), agreement (billed or pre-paid), reading date and change date. It stores the from and to readings and their dates, units consumed, status of data, who reported and recorded the data, cost of the consumption invoice data (supplier, invoice number and line number), tariff verification codes and statuses, the quality code, additional comments and whether the record is active or inactive.

 

If the user has access to the function via the profile Consumption Data Maintainer without the ‘Add’ option, the INSERT button will be disabled. It will also be disabled if the user does not have access to CAPture data via the Consumption Status Authorization function. If the profile is given without the ‘Change’ option, the other statuses after Capture will not be available to them. Similarly, the user will not be able to mark a record as DELeted if the ‘delete’ option on the profile was not given to him,/her.

The status privileges are allocated to users via the Consumption Status Authorization function. These privileges are may be allocated per profile as mentioned above, person, per role in predefined tables. See detail in the Consumption Status Authorization function Help section. The access is given by sub region, product code or measurement type.

 

The user must select the Sub Region as a minimum entry to display existing data. (They can then select the Branch Code, City or the Location or even the Consumption Category or DOL Code to minimize the data options displayed.) Most users will be limited to a specific sub-region. There will be users that are entitled to see all the data and will then be allowed to select ‘ALL’ in the Sub region field and display everything. Please note that it is inadvisable to try and view all historical data on-line. This data may be viewed by going to Reporting Services on the intranet and selecting one of the many available standard or customized reports.

 

The Sub Region field is populated from the sub regions existing in the City table. The sub regions that are displayed are limited by the records in the Consumption_Authorization_Status which allow certain users to see the data for certain sub regions. When the Sub region is selected, the City field is automatically limited to cities within the Sub region. The Sub Region is mandatory. If this field is not entered, the Show button is disabled.

The City field is populated from the City table. When the City is selected, the Locations are limited to those belonging to the selected City.

The Sub region and City fields will limit the selection of the location and organizations in the grid as well as the location in the parameters.

The Branch Code is populated from the Location_Master_Organisation table where the type is 1 and the descriptions of the cost centers will be found in the Cost_Centre table. The user must enter the branch code to populate this parameter.

If the City is selected, the branch field is disabled and vice versa. To re-enable the city or branch fields, please click on the Clear Keys button.

The selection of the branch also limits the locations available for selection in the parameter drop down as well as the grid.

The Locations are populated from the Location_Master table if the City is selected. If the Branch is selected, locations are populated from the Location_Master_Organisation table. If neither is selected, the Location Master table is used.

The locations populated here may be active or inactive to allow all history to be viewed. The effective date on the Location Master history table applies to all fields but is not read when displaying active or inactive buildings. This field is interpreted as either currently inactive or currently active.

When Locations are selected, these limit the population of the (external) organization in the grid.

Note that the words external organization and suppliers are interchangeable. The words branch, cost centre and internal organisation are interchangeable.

 

Consumption Categories are populated from the Part_Master table where the commodity code is 'CATEG'.

The consumption categories that may be used are limited by the records in the Consumption_Status_Authorization function which allow certain users to perform updates for certain  product codes only. For example, if the user is given access to CAPture the product code ‘DEC’ (Direct Energy Consumption), then only parts (categories) linked to the product code DEC may be captured by the logged-on user.

The selection of the Consumption Category will result in the defaults being automatically entered in the DOL code and Action Code fields (as set up in the Equipment DOL Action Defaults and the Equipment DOL Action Allowed functions). These may be changed if more than 1 DOL Code and/or Action Code has been linked to the category.

 

The screen defaults to the Financial Period (and the start fin period of the current financial year and the current end fin period) but the user may select the Reading Date option. In either case, the data displayed is limited to that between the ‘from’ and ‘to’ - periods / reading dates displayed.

 

The screen also defaults to ‘Buildings’. This allows the display of only building types (and in this case, those that have no parent). Should this be unchecked, the data for all other location types will be displayed.

The screen also defaults to ‘Active’ data. Data is considered ‘Inactive’ when it is in status DELETED. No physical deletes of data is allowed once entered.

The screen also defaults to show ‘Accepted Consumption Records’. This means that it displays only the measurement type with the highest rating. Unchecked, it displays all the records created with lower rated measurement types. For example, should two records exist for the same category, location  and reading date, the one with a measurement type of ‘SUPPL AVERAGE’ and the other of ‘METER READING’, the default will display only the record with a measurement type of ‘SUPPL AVERAGE’ because it has a rating of 2 and the METER READING has a rating of 3.

The screen also defaults to show ‘Billed’ and ‘Prepaid’ agreement records.

 

 

The Tariff Verification Code field is populated from the Tariff_Verification_Code table. It limits the data displayed to those records with this code.

The Tariff Verification Status field is populated from the Tariff_Verification_Status table. It limits the data displayed to those records with this code.

 

The Status field allows the user to display all records existing with the selected status. The status is populated from the Consumption_Status table. Note that this is a very valuable entry to allow the user wishing to change data from one status to the next to display only the relevant data.

The Change Status To field allows the user to prepopulate all displayed fields with the status to which he/she would like to change the data. The status is populated from the Consumption _Status table. It is also limited by the Consumption_Status_Authorization table’s records which determine what each user may do.

 

 

The INSERT ROW allows the user to insert a new blank row at the bottom of all the displayed data. The CLEAR GRID clears the grid of all data (it does not delete any data). This is used when there is a lot of data on the screen and the user wants to enter new data without having to scroll to the bottom to enter data on the last (available) line after clicking on INSERT ROW.

CLEAR KEYS allows the user to delete all the parameters previously entered and to start from scratch.

SHOW displays all the data that complies with the parameters entered and or defaults on the top part of the screen (above the grid).

GUESSTIMATE displays the Consumption Guesstimate modal screen which allows the user to enter an estimate in the consumption units field. See below for details.

 

The grid :

 

If the Location is selected as a parameter, it does not display in the grid. It is in fact hidden in the grid. The data displayed or entered will then automatically contain said location.

The locations available for selection in the grid are limited to those linked to the sub region on the City table via the Consumption_Status_Authorization table’s records for the logged-on employee.

It populates from the Location Master function.

 The locations populated here must be active to ensure only active locations (buildings) are selected. The                effective date on the Location Master history table applies to all fields but is not read when displaying active        or inactive buildings. This field is interpreted as either currently inactive or currently active.

They are also limited by the Sub Region, City and Location parameters selected at the top of the screen.

 

If the Consumption Category is selected as a parameter, it does not display in the grid. It is in fact hidden in the grid. The data displayed or entered will then automatically contain said category DOL code and Action code. The data available for selection is limited by the Consumption Category parameter selected at the top of the screen. The DOL Code and Action codes will default to that which is linked to the consumption category via the Equipment DOL Action Defaults function and be limited to those already set up in the Equipment DOL Action Allowed function.

 

The agreement is also part of the key. It is the type of billing (contractual agreement) of the record. The current values are Billed or Pre-paid. These are determined in the Column Values table.

 

The reading date is a calendar day. More than 1 record for the same day is allowed because the change date is also part of the key and the system will be able to maintain a separate record. At present the system allows only a single record per reading date (per category, location, DOL code, action code, agreement, measurement type and status).

The reading date determines the financial period and thus the period in which the consumption is reported.

It is important that the user select the correct reading date when recording the data. This date must coincide with the reading date on the invoice (as this is the date that can not be controlled by the user). The user must also ensure that the same reading date is selected when creating alternative measurement type records for the same period. By this we mean the following : If a meter reading is taken, it should be taken on the same date as that recorded on the invoice (or as close as possible to it).If the actual reading was not taken on the same day, the actual day it was taken may be stored in the comments field but the reading date selected must match that of the invoice reading date. If a guesstimate record is created, it should also contain exactly the same reading date as that of the invoice reading date. So, all 3 records should be saved with the same reading date in order for the system to categorize them as pertaining to the same ‘incident’.

Should the business decision be made that the reading date is not the invoice date, for example because the invoice date is later than the date of the consumption and thus gives a false reflection of the consumption per financial period, the date chosen must be adhered to by all users – i.e. if the end reading date is selected, then that is the date that must always be used for consumption capture. This is vital as it affects the consumption displayed per financial periods because the reading date’s financial period is used in all reports as the consumption period.

 

The measurement types available for selection are limited by the measurement types allowed in the  Consumption_Status_Authorization table. This is populated either from the Measurement Type parameter already selected at the top of the screen or from the Consumption_Measurement_Type table.

Four standard types exist namely : SUPPL ACTUAL , SUPPL AVERAGE, GUESSTIMATE and METER READING. The first 2 relate to invoice data. The guesstimate is required if the invoice is late or unavailable or projections are required for future periods. If the option GUESSTIMATE is chosen, a Consumption Guesstimate modal screen will pop up. It aids the user in creating an estimate for input in the consumption units field. METER READING is the reading read manually from the meter itself. In the future, this will be automated and the readings taken by a meter reader may be sent through automatically to the consumption data table. The rating of this measurement type may then replace that of the invoice (SUPPL ACTUAL) as the one most trusted.

 

The Acceptance Indicator is determined by the system. It will update a record with the same key (and different measurement type) to either a 1 or a zero. The record with the highest rated measurement type will be the one with the Acceptance Indicator of 1 and the others with a zero. If a record is added with a measurement type containing a higher rating, the others will

automatically be ‘down adjusted’ to a zero value and it will be saved as the ‘accepted’ record.

 

The Start Reading and End Reading Dates save the “from” and “to” reading dates recorded on the invoice.

 

The Consumption Units save the actual total units measured/recorded/read. The DOL code or unit of measure is displayed next to the units so users can see what “kind” of units they are recording.

 

The Start Reading and End Reading Units save the “from” and “to” readings recorded on the meter or invoice.

Note that the system will give a warning message if the start and end unit readings or start and end reading units don’t tie up with the consumption units. It will also warn the user if the start reading date does not match with the end reading date of the maximum previous reading date’s record with the same key (except the reading date and measurement type)

 

The system will also default the start reading date to a day after the last end reading date and the start reading units to that of the last end units reading for the next record with the same key (consumption category, location, measurement type, agreement)

 

The Meter Unit Number is the number given to that specific meter that was read.

 

For new records, the DOL Code and Action Code fields are populated from the DOL_Action_ Allowed table for the specific category that has been selected.

 

New Status is populated with the statuses that the logged-on user is allowed to use. This is determined by the data in the Consumption_Status_Authorization table.

 

The Amount is the Consumption cost for that specific category. It is only relevant where the measurement type is SUPPL ACTUAL or SUPPL AVERAGE. It is seldom the total of the invoice as the invoice often comprises many categories e.g. electricity demand, consumption, reactive and municipal water.

If the measurement types SUPPL AVE or SUPPL ACT have been used in a consumption record, the amount is enforced.

If the measurement types GUESStimate  or METER reading have been used and the amount is not entered, the system calculates it for the user if rates exist to do so.

 

Organisation Code is that of the supplier. It populates in alphabetical order from the Location_Master_Organisation table where the type is 2 (vendor/external), but is limited by the sub region allowed in the  Consumption_Status_Authorization table and displayed at the top of the screen.

 

The invoice number field allows the user to type in a new invoice number or select one that already exists in the Invoice table (as yet unlinked to the Consumption data table). The invoice line number will be populated automatically once the link is made.

The Organisation Code and Invoice Number fields are enabled only for measurement types SUPPL ACTUAL and SUPPL AVERAGE HERE as the other measurement types do not pertain to an invoice.

Once these fields are filled in, the field with the 3 ellipses is also then ‘enabled’ and allows the user to jump to the Consumption Invoice modal screen. This screen allows the user to enter all the required information on an invoice. This data is then stored in the Invoice, Invoice_Line and Invoice_Line_Link tables.

 

The Tariff Plan populates from the equipment_dol_consump_tariff. It is not mandatory. The user must ensure that the plan is selected if it is applicable. If they do not select the plan and the tariff has been created and linked to a plan, the system will not verify the rate correctly.

 

The Tariff Verification Code is defined in the Tariff_Verification_Code table. It is automatically calculated by the system. If the Amount that is entered (or defaulted into the field from the Consumption Invoice screen) is correct according to the rates entered in the Consumption Tariff screen  (for rates per building per supplier per category (and for rates without reference to a building)), the system will default a value of CORRECT in the field. The system also defaults the value ‘CANT CALC’ into the field for all migrated data where no rates have been calculated. If the amount is too high, OVERCHARGED will appear and UNDER CHARGED for the reverse. If no rates can be found, ‘NO RATE’ will be populated into the field. The Consumption Tariff screen is populated from the Equipment_DOL_Consump_Tariff table.

The Tariff Verification Status is defined in the Tariff_Verification_Status table. The system will default spaces into the field if the code field is CORRECT. If OVERCHARGED is displayed in the code field, the status will default to INVESTIGATING. Once the investigation has taken place and a solution found to the satisfaction of the user, he/she may change the field to ‘ACCEPTED’ which means that the invoice will be / has been rectified in the next month or the rate was incorrect in the system.

 

A specific profile exists to enable a user to make changes to a carbon consumption record that specifically affects the rate verification. It is called Consumption Tariff STATUS Maintainer. Should the user have this profile (and the change option), he/she may make changes to the Tariff Verification Status without the system recalculating and thus changing the Tariff Verification Code. In all other cases, if the status is between CAP and MAN, the system will recalculate the Tariff verification code and update the Tariff Verification Status automatically. This means that the code will be updated automatically but the auto-calculated status can be over-written. The user with the abovementioned profile may also then update the tariff status if the system has given a warning about other issues e.g. start and end units/dates..

 

 

The DOL Code and Action codes will default to that which is linked to the consumption category via the Equipment DOL Action Defaults function and be limited to those already set up in the Equipment DOL Action Allowed function.

 

The Quality Code is populated from the Consumption_Quality_Code table. The system defaults a value of 3 (‘AVERAGE’) into the system data. If the user wishes to change this value, he./ she may just select another code.

 

The Recorded By field id disabled and automatically stores the employee id of the logged-on user. This forms an important part of the audit trail.

 

The Reported By field populates from the Employee Master table. This stores the employee id of the person who reported the data and would most often relate to the person reporting the meter reading. It is not mandatory.

 

The Comments field allows free text and will store anything the user considers pertinent.

 

The Active indicator is always set to 1 unless an authorized user has set a record to the status ‘DELETED’ , in which case all the records for this key will be marked as Inactive (0). Note that when a record set is made inactive, the system does not remove the link between it and the invoice  (if there was one). It will however allow that invoice to be linked to another record because the system excludes the inactive records in its search when allowing an invoice to be linked (i.e. it will not find a duplicate).

 

The following fields in the grid are mandatory : The Location, Consumption Category, DOL and Action Codes, Reading Date, Agreement, Measurement Type and Quality Code. The rest of the fields are important for various reasons and should not be blank. The Comments field is an exception.

The organization code, invoice number (and line) are mandatory if the status is in MANager approved status. The only exception here is the agreement PRE-PAID. This does not enforce anything other than the key, units and the Rand value. Note that the agreement PRE-PAID applies only to SUPPLier ACTUAL and METER reading measurement types, but the meter reading has no invoice data.

 

The system does not allow changes to any field with the exception of the Tariff Verification Status if the user has the profile ‘Consumption Tariff STATUS Maintainer’. This profile allows the change to status without a recalculation of the Tariff Verification Code.

All ‘updates’ or changes to the status of a record are actually an insert of a new record.

No history is discarded.

Should a record be incorrect and the user has the status authorization of “DELete’, he/she may change the status to Deleted and all associated records will be marked as Inactive – i.e. all records with the same Location, Consumption Category, Reading Date and Measurement Type will be marked as inactive. (Note that this means all the statuses these records have ever been in will also become inactive.) The idea behind this is that a new set of records should be allowed to be added that are not incorrect. These will have to start in the status CAP and possibly work its way up the status ladder.

Reading start and end dates and units, comments and invoice related data may be added or changed until the record is in MAN status.

Invoice data may be entered at the last minute as the person with MAN status authorization makes it MAN approved.

No other fields may be changed after CAPtured status.

 

Note that the system will give a warning message if the start and end unit readings or start and end reading units don’t tie up with the consumption units. It will also warn the user if the start reading date does not match with the end reading date of the maximum previous reading date’s record with the same key (except the reading date and measurement type)

Tariff verification status changes will also create a warning message (up to status MAN)

Warning messages do not prevent the system from creating the record.

Warning records may be viewed by clicking on the Capture Errors tab (2nd tab). Double-clicking on the error will take the user back to the record in which the error occurred on the 1st tab  - Capture Consumption Data.

 

A few other rules exist :

A record may not be added if the new and existing record is in the same status.

When changing the status of a record, the result is a new record with the latest change date. This addition will affect the accepted record. It may result in the previous accepted record no longer being so, or it may be that due to its measurement type, the previous older record is still the accepted record.

Once a record has been rejected, the sequence is required to go backwards, otherwise always forwards. The statuses DELeted and AUDIT approvals have no sequence. They can fit in at any stage. This means for example, once a record has gone from status CAP (sequence 1) to MAN (sequence 3) and the MREJ(seq 4), it may only go back and become MAN (seq 3), VER (seq 2) or CAP (seq 1) again after that !

When linking a consumption record (SUPPL ACTUAL/AVE) to an invoice, the link class and consumption category must match. One cannot link an invoice to a consumption record where the former has a link class of only ‘ELECTRICITY DEMAND’ and the latter’s line is ‘ELECTRICITY CONSUMPTION COMB’. The system will see that as an error and disallow the link between the two.

Normally, the same person cannot make a change to the status if they have made the last change. The exception is when a record’s status is changed by person x and tehn they realsie they have made a mistake. They can then status REJect the record.

 

New consumption data may not be added if the financial period is closed. The financial period open- and closing is controlled by the Consumption Status Authorization table, 2nd tab called Consumption Financial Period.

 

The relevant table is Equipment_DOL_Consump_Type_History.