Spreadsheet: chris_stokley__3966__Entity_Attribute_Definition_Note 09_06_2001
Sheet: Entity_Attribute_Definitions_No

Entity |  |  | Attribute
Name | Definition | Note | Name | Definition | Note
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | [NAME] | The data warehouse's unique identifier for a SUPPLIER Bill
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM from which this row was created and/or updated
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | BILL_ID | The SOURCE_SYSTEM's identifier for a BILL
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | SEND_DATE | The date on which one or more BILL_LINE's were sent to the Accounts Payable subledger, and booked as a liability (or the date that the billing system assumes the liability is booked)
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | DUE_DATE | The SUPPLIER assigned date by which the BILL must be paid to the SUPPLIER
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | ISSUE_DATE | The date on which the SUPPLIER issued the BILL.
BILL | A BILL represents a bill sent by a SUPPLIER to ENRON.  In other words, it represents an Enron liability to a SUPPLIER.  The AP_ACTION_CODE in the BILL_LINE_FACT indicates whether the liability has been posted to the Accounts Payable subledger. |  | JOB_KEY | The job which created the row
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | [NAME] | DW unique identifier of a BILL_LINE_FACT row.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | COMPANY_KEY | The data warehouse's unique identifier for an Enron book of accounts.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | CUSTOMER_ACCOUNT_KEY | The data warehouse's unique identifier of a CUSTOMER_ACCOUNT
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | SUPPLIER_KEY_TRANSDIST | The data warehouse unique identifier for a SUPPLIER.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | GL_ACCOUNT_KEY_BILLING | The data warehouse unique identifier for a GL account
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | GL_ACCOUNT_KEY_BILLING_OFFSET | The data warehouse unique identifier for a GL account
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | GL_ACCOUNT_KEY_AP | The data warehouse unique identifier for a GL account
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | GL_ACCOUNT_KEY_AP_OFFSET | The data warehouse unique identifier for a GL account
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | [NAME] | The data warehouse's unique identifier for a SUPPLIER Bill
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | BILL_ID | The SOURCE_SYSTEM's unique identifier of the BILL
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | BILL_LINE_ITEM_ID | The SOURCE_SYSTEM's unique identifier of the [NAME]
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | PRODUCTION_MONTH | A month on which the MASTER_SERVICE was realized/consumed.  The Fact contains the BILL_LINE's contribution, in terms of dollars and unit volume, to the PRODUCTION_MONTH
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | LINE_DESCRIPTION | The description of the line item
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | CHARGE_CODE | A code indicating the type of charge that the BILL_LINE represents
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | ALLOCATED_AMOUNT | The BILL_LINE amount/the number of days in the PRODUCTION_MONTH.  Only dollars that are posted against GL_ACCOUNT_KEY_BILLING_OFFSET should be represented in this column
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | ALLOCATED_UNITS | The BILL_LINE volume/the number of days in the PRODUCTION_MONTH.  Only units that are posted to a GL_ACCOUNT_KEY_BILLING_OFFSET should be represent in this column
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | AP_ACTION_CODE | Indicates whether the line item was posted to the AP subledger.  Possible Values: 0 = 'Not posted to AP subledger' 1 = 'Posted to AP subledger'
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | AR_ACTION_CODE | Indicates whether the BILL_LINE item should be recouped from the BILLING_CUSTOMER via an INVOICE, not recouped, or display only.  This code is SOURCE_SYSTEM_DEPENDENT.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | NON_CONSUMPTION_UNITS | In the case where CONSUMPTION_TYPE = 2, the consumption units will be found in the NON_CONSUMPTION_UNITS column (instead of the ALLOCATED_UNITS column). | This column will be populated with V6 of the data model.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | [NAME] | Contains all dollars which do NOT impact the subledger (or have already impacted the subledger in a prior BILL).  In the case where DOLLARS_TYPE = 2, the dollars will be found in the NON_FINANCIAL_DOLLARS column (instead of the ALLOCATED_AMOUNT column). | This column will be populated with V6 of the data model.
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | FROMDATE | The first date on which the MASTER_SERVICE was consumed/realized (or first date of the bill-cycle).
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | TODATE | The last date on which the MASTER_SERVICE was consumed/realized (or last date of the bill-cycle).
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | RATE | The multiplier used to calculate the LINE_ITEM's dollars
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | UNIT_OF_MEASURE | The unit of measure associated with the ALLOCATED_UNITS or NON_CONSUMPTION_UNITS
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | VOLUME_TYPE | The type of volume that the BILL was based on  Examples: . Nominated (based on nomination) . Actual (based on actual) . Estimate (based on estimate which is different than the nomination)
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | CURRENCY_TYPE | The currency in which the MASTER_SERVICE was invoiced
BILL_LINE_FACT | A BILL_LINE_FACT represents the contribution, in terms of dollars and unit volume, of one line item towards a PRODUCTION_MONTH.  The PRODUCTION_MONTH represents a month over which a MASTER_SERVICE was realized (or consumed). |  | JOB_KEY | The job that created the row
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | BILLING_CUSTOMER_KEY | The data warehouse's unique identifier for the BILLING_CUSTOMER
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | GCP_KEY | The data warehouse's unique identifier for the GCP.
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's identifier for the BILLING_CUSTOMER
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | BILLING_CUSTOMER_NAME | The name of the BILLING_CUSTOMER
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | STREET_ADDRESS_1 | 1st row of the BILLING_CUSTOMER's street address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | STREET_ADDRESS_2 | 2nd row of the BILLING_CUSTOMER's street address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | CITY | The city of the BILLING_CUSTOMER's address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | COUNTY | The county of the BILLING_CUSTOMER's address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | STATE_KEY | The state of the BILLING_CUSTOMER's address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | ZIP_5 | The 5 digit zip code of the BILLING_CUSTOMER's address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | [NAME] | The 4 digit zip code suffix of the BILLING_CUSTOMER's address
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | JOB_KEY | The job which created this row
BILLING_CUSTOMER | The customer as defined by the billing system.  The BILLING_CUSTOMER may have one or more PHYSICAL_LOCATIONs with each receiving one or more MASTER_SERVICEs.  The BILLING_CUSTOMER may have one or more INVOICING_GROUPS each receiving and/or paying INVOICEs. | Priority: High Will need to track history. | UPDATE_JOB_KEY | The job which updated this row
COMPANY | A financial accounting book of business.  e.g. EESO or EEMC. |  | COMPANY_KEY | The data warehouse's unique identifier for an Enron book of accounts.
COMPANY | A financial accounting book of business.  e.g. EESO or EEMC. |  | COMPANY_NAME | The name of the Enron book of business.  Possible Values:  1 = 'EEMC' 2 = 'EESO' 0 = 'Unknown'
COMPANY | A financial accounting book of business.  e.g. EESO or EEMC. |  | JOB_KEY | The job that created the row
COMPANY | A financial accounting book of business.  e.g. EESO or EEMC. |  | UPDATE_JOB_KEY | The job that updated the row
CONSUMPTION_TYPE | Indicates whether the unit volume of the LINE_FACT represents actual consumption or display only consumption (non-consumption units).  If the [NAME] contains non-consumption units, the units will exist in the NON_CONSUMPTION_UNITS column so they will not be mingled with actual consumption that was posted against a GL_ACCOUNT. |  | CONSUMPTION_TYPE_KEY | The data warehouse's key indicating what type of consumption is represented in the line item. | This column will be populated with V6 of the data model.
CONSUMPTION_TYPE | Indicates whether the unit volume of the LINE_FACT represents actual consumption or display only consumption (non-consumption units).  If the [NAME] contains non-consumption units, the units will exist in the NON_CONSUMPTION_UNITS column so they will not be mingled with actual consumption that was posted against a GL_ACCOUNT. |  | CONSUMPTION_TYPE_NAME | The name of the consumption type  Possible Values: 1 = 'Consumtion Units' 2 = 'Non-Consumption Units' | This column will be populated with V6 of the data model.
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | CUSTOMER_ACCOUNT_KEY | The data warehouse's unique identifier of a CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | PHYSICAL_LOCATION_KEY | The data warehouse's unique identifier for a BILLING_CUSTOMER's PHYSICAL_LOCATION
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | MASTER_SERVICE_KEY | The data warehouse's unique identifier of a MASTER_SERVICE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | CUSTOMER_TYPE_KEY | The data warehouse's unique identifier of a CUSTOMER_TYPE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | PRODUCT_KEY | The data warehouse's unique identifier of the PRODUCT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SERVICE_STATUS_KEY | The data warehouse's unique key indicating a status condition
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | RATE_SCHEDULE_KEY | The data warehouse's unique identifier for a RATE_SCHEDULE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | PHYSICAL_INDICATOR_KEY | The data warehouse's code indicating whether Enron is responsible for delivering the MASTER_SERVICE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | EVERGREEN_INDICATOR_KEY | The data warehouse's code indicating the Evergreen Status of the CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's unique identifier for the CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | CUSTOMER_ACCOUNT_NAME | The name of the CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | INVOICING_DAY | When this customer is invoiced (every Wed, on the fourth, etc)
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SUPPLIER_KEY | The SUPPLIER responsible for providing the MASTER_SERVICE to the BILLING_CUSTOMER'S PHYSICAL_LOCATION
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SUPPLIER_ACCOUNT_ID | The SUPPLIER's unique identifier of the CUSTOMER_ACCOUNT
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | START_DATE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | END_DATE
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | EFFECTIVE_DATE | The EFFECTIVE_DATE & TERMINATION_DATEs are used to track history on a PHYSICAL_LOCATION.    When a field, on which history is being tracked, changes a new row is created in the PHYSICAL_LOCATION table containing the new state of the field.  The first rows' TERMINATION_DATE will be set to one day prior to the EFFECTIVE_DATE of the new row.
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | TERMINATION_DATE | The EFFECTIVE_DATE & TERMINATION_DATEs are used to track history on a PHYSICAL_LOCATION.    When a field, on which history is being tracked, changes a new row is created in the PHYSICAL_LOCATION table containing the new state of the field.  The first rows' TERMINATION_DATE will be set to one day prior to the EFFECTIVE_DATE of the new row.
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | JOB_KEY | The job that created the row
CUSTOMER_ACCOUNT | Each row in this dimension represents the association of a BILLING_CUSTOMER's PHYSICAL_LOCATION with a MASTER_SERVICE.  e.g. a physical location receiving the gas commodity.  Once this entity begins to be used to track history, the same physical location / commodity association may appear in multiple rows (e.g. representing when attributes about the assoication change).  However, at any point in time, one and only one row for an association will be valid.  The row which is valid at a point in time can be determined by the rows' EFFECTIVE_DATE and TERMINATION_DATE. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the CUSTOMER_ACCOUNT.  This will be required because once history is supported, each row in the CUSTOMER_ACCOUNT dimension (and hence the CUSTOMER_ACCOUNT) will represent a snapshot of a CUSTOMER_ACCOUNT over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | UPDATE_JOB_KEY | The job that updated the row
CUSTOMER_TYPE | e.g. Industrial, Commercial, Residential, TEM, Agriculture, Wholesale, etc. |  | CUSTOMER_TYPE_KEY | The data warehouse's unique identifier of a CUSTOMER_TYPE
CUSTOMER_TYPE | e.g. Industrial, Commercial, Residential, TEM, Agriculture, Wholesale, etc. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
CUSTOMER_TYPE | e.g. Industrial, Commercial, Residential, TEM, Agriculture, Wholesale, etc. |  | CUSTOMER_TYPE_NAME | The name of the CUSTOMER_TYPE
CUSTOMER_TYPE | e.g. Industrial, Commercial, Residential, TEM, Agriculture, Wholesale, etc. |  | JOB_KEY | The job which created the row
CUSTOMER_TYPE | e.g. Industrial, Commercial, Residential, TEM, Agriculture, Wholesale, etc. |  | UPDATE_JOB_KEY | The job which updated the row
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | EVENT_DATE | Date of DAY
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | YEAR_CODE | The four digit year of that the DAY belongs to.
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | QUARTER_CODE | Calender Quarter that the DAY belongs to  Possible Values:  1 - January to March 2 - April to May 3 - June to August 4 - September to December
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | MONTH_CODE | The number of the month that the DAY belongs to.  e.g. 7 for July.
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | DAY_CODE | The day of the month, ie the 12th.
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | JOB_KEY | The Job which created the row.
DAY | A calandar DAY.    Each DAY will be identified by its date.  Each DAY will be associated with its calandar month, quarter and year. |  | UPDATE_JOB_KEY | The job which updated the row.
DEV14 |  |  | DUMMY
DOLLARS_TYPE | Indicates whether the dollars of the LINE_FACT represents financially impacting dollars or display only non-financially impacting dollars.  If the [NAME] contains non-financially impacting dollars, the dollars will exist in the NON_FINANCIAL_DOLLARS column so they will not be mingled with actual dollars that were posted against a GL_ACCOUNT. |  | DOLLARS_TYPE_KEY | The data warehouse's key indicating the type of dollars represented in the line item | This column will be populated with V6 of the data model.
DOLLARS_TYPE | Indicates whether the dollars of the LINE_FACT represents financially impacting dollars or display only non-financially impacting dollars.  If the [NAME] contains non-financially impacting dollars, the dollars will exist in the NON_FINANCIAL_DOLLARS column so they will not be mingled with actual dollars that were posted against a GL_ACCOUNT. |  | DOLLARS_TYPE_NAME | The name of the DOLLARS_TYPE  Possible Values: 1 = 'Financial Dollars' 2 = 'Non-Financial Dollars' | This column will be populated with V6 of the data model.
EVERGREEN_INDICATOR | Indicates whether the some percentage of the MASTER_SERVICE consumed by the CUSTOMER_ACCOUNT will be sourced from renewable energy sources. |  | EVERGREEN_INDICATOR_KEY | The data warehouse's code indicating the Evergreen Status of the CUSTOMER_ACCOUNT
EVERGREEN_INDICATOR | Indicates whether the some percentage of the MASTER_SERVICE consumed by the CUSTOMER_ACCOUNT will be sourced from renewable energy sources. |  | EVERGREEN_INDICATOR_DESCRIPTIO | Description of the EVERGREEN_KEY
EVERGREEN_INDICATOR | Indicates whether the some percentage of the MASTER_SERVICE consumed by the CUSTOMER_ACCOUNT will be sourced from renewable energy sources. |  | JOB_KEY | The job which created the row
EVERGREEN_INDICATOR | Indicates whether the some percentage of the MASTER_SERVICE consumed by the CUSTOMER_ACCOUNT will be sourced from renewable energy sources. |  | UPDATE_JOB_KEY | The job which updated the row
GCP | Global Counterparty (GCP)  An Enron Customer with whom Enron has a contract with to provide one or more MASTER_SERVICES to one or more PHYSICAL_LOCATIONS.    A GCP may be the parent of one or more BILLING_CUSTOMERs.  In fact, the GCP is the mechanism, which is used by Enron, to identify which  BILLING_CUSTOMERs across SOURCE_SYSTEMs are actually the same customer. | This table will be populated in V7 of the data model. | GCP_KEY | The data warehouse's unique identifier for the GCP.
GCP | Global Counterparty (GCP)  An Enron Customer with whom Enron has a contract with to provide one or more MASTER_SERVICES to one or more PHYSICAL_LOCATIONS.    A GCP may be the parent of one or more BILLING_CUSTOMERs.  In fact, the GCP is the mechanism, which is used by Enron, to identify which  BILLING_CUSTOMERs across SOURCE_SYSTEMs are actually the same customer. | This table will be populated in V7 of the data model. | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
GCP | Global Counterparty (GCP)  An Enron Customer with whom Enron has a contract with to provide one or more MASTER_SERVICES to one or more PHYSICAL_LOCATIONS.    A GCP may be the parent of one or more BILLING_CUSTOMERs.  In fact, the GCP is the mechanism, which is used by Enron, to identify which  BILLING_CUSTOMERs across SOURCE_SYSTEMs are actually the same customer. | This table will be populated in V7 of the data model. | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's unique identifier for the GCP
GCP | Global Counterparty (GCP)  An Enron Customer with whom Enron has a contract with to provide one or more MASTER_SERVICES to one or more PHYSICAL_LOCATIONS.    A GCP may be the parent of one or more BILLING_CUSTOMERs.  In fact, the GCP is the mechanism, which is used by Enron, to identify which  BILLING_CUSTOMERs across SOURCE_SYSTEMs are actually the same customer. | This table will be populated in V7 of the data model. | GCP_NAME | The name of the GCP
GCP | Global Counterparty (GCP)  An Enron Customer with whom Enron has a contract with to provide one or more MASTER_SERVICES to one or more PHYSICAL_LOCATIONS.    A GCP may be the parent of one or more BILLING_CUSTOMERs.  In fact, the GCP is the mechanism, which is used by Enron, to identify which  BILLING_CUSTOMERs across SOURCE_SYSTEMs are actually the same customer. | This table will be populated in V7 of the data model. | JOB_KEY | The job which created the row
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | GL_ACCOUNT_KEY | The data warehouse unique identifier for a GL account
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | SOURCE_SYSTEM_KEY | A reference to the SOURCE_SYSTEM from which the row came from
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM'S identifier for the GL account.  This may be the same as the actual GL_ACCOUNT_CODE.
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | GL_ACCOUNT_CODE | The SOURCE_SYSTEM'S code representation of a GL account.
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | GL_ACCOUNT_NAME | The name of a GL account.  e.g. 'Power Sales', 'LDC Pass Thru', etc.
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | UPDATE_JOB_KEY | The job that updated the row
GL_ACCOUNT | This entity contains a master list of financial accounts against which business transactions are posted. |  | JOB_KEY | The job that created the row
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | INVOICE_KEY | The data warehouse's unique identifier for an INVOICE
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM from which the row was created and/or updated
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | INVOICE_ID | The SOURCE_SYSTEM's identifier for the INVOICE
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | SEND_DATE | The date on which one or more INVOICE_LINE's were sent to the Accounts Receivable subledger, and booked (or the date that the billing system assumes the receivable is booked)
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | DUE_DATE | The date by which PAYMENT for the INVOICE must be received by ENRON
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | ISSUE_DATE | The date on which the INVOICE was created
INVOICE | An INVOICE represents an invoice sent by ENRON to a BIILLING_CUSTOMER's INVOICING_GROUP.  In other words, it represents a customer's liability to ENRON.  The DOLLARS_TYPE attribute in the INVOICE_LINE_FACT indicates whether the liability has been posted to the Accounts Receivable subledger. |  | JOB_KEY | The job which created the row
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | INVOICE_LINE_FACT_KEY | The data warehouse's unique identifier for the INVOICE.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | COMPANY_KEY | The data warehouse's unique identifier for an Enron book of accounts.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | INVOICING_GROUP_KEY | The data warehouse's unique identifier for the INVOICING_GROUP
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | CUSTOMER_ACCOUNT_KEY | The data warehouse's unique identifier of a CUSTOMER_ACCOUNT
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | SUPPLIER_KEY_TRANSDIST | The data warehouse unique identifier for a SUPPLIER.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | GL_ACCOUNT_KEY_BILLING | The data warehouse unique identifier for a GL account
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | GL_ACCOUNT_KEY_BILLING_OFFSET | The data warehouse unique identifier for a GL account
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | GL_ACCOUNT_KEY_AR | The data warehouse unique identifier for a GL account
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | GL_ACCOUNT_KEY_AR_OFFSET | The data warehouse unique identifier for a GL account
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | INVOICE_KEY | The data warehouse's unique identifier for an INVOICE
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | INVOICE_ID | The SOURCE_SYSTEM's unique identifier for the INVOICE
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | [NAME] | The data warehouse's unique identifier for a SUPPLIER Bill
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | INVOICE_LINE_ITEM_ID | The SOURCE_SYSTEM's unique identifier of the INVOICE_LINE
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | PRODUCTION_MONTH | A month on which the MASTER_SERVICE was realized/consumed.  The Fact contains the INVOICE_LINE's contribution, in terms of dollars and unit volume, to the PRODUCTION_MONTH
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | LINE_DESCRIPTION | The description of the INVOICE_LINE
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | CHARGE_CODE | A code indicating the type of charge that the BILL_LINE represents
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | ALLOCATED_AMOUNT | The BILL_LINE amount/the number of days in the PRODUCTION_MONTH.  Only dollars that are posted against GL_ACCOUNT_KEY_BILLING_OFFSET should be represented in this column.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | ALLOCATED_UNITS | The BILL_LINE volume/the number of days in the PRODUCTION_MONTH  Only units that are posted to a GL_ACCOUNT_KEY_BILLING_OFFSET should be represent in this column
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | CONSUMPTION_TYPE_KEY | The data warehouse's key indicating what type of consumption is represented in the line item. | This column will be populated with V6 of the data model.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | DOLLARS_TYPE_KEY | The data warehouse's key indicating the type of dollars represented in the line item | This column will be populated with V6 of the data model.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | NON_CONSUMPTION_UNITS | In the case where CONSUMPTION_TYPE = 2, the consumption units will be found in the NON_CONSUMPTION_UNITS column (instead of the ALLOCATED_UNITS column). | This column will be populated with V6 of the data model.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | [NAME] | Contains all dollars which do NOT impact the subledger (or have already impacted the subledger in a prior INVOICE).  In the case where DOLLARS_TYPE = 2, the dollars will be found in the NON_FINANCIAL_DOLLARS column (instead of the ALLOCATED_AMOUNT column). | This column will be populated with V6 of the data model.
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | TODATE | The last date on which the MASTER_SERVICE was consumed/realized (or last date of the bill-cycle).
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | FROMDATE | The first date on which the MASTER_SERVICE was consumed/realized (or first date of the bill-cycle).
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | CURRENCY_TYPE | The type of currency in which the [NAME] was invoiced
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | RATE | The multiplier used to calculate the LINE_ITEM's dollars
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | UNIT_OF_MEASURE | The unit of measure associated with the ALLOCATED_UNITS and NON_CONSUMPTION_UNITS
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | VOLUME_TYPE | The type of volume that the BILL was based on  Examples: . Nominated (based on nomination) . Actual (based on actual) . Estimate (based on estimate which is different than the nomination)
INVOICE_LINE_FACT | This fact represents the contribution of an invoice line item, in terms of volume and dollars, towards a production month.  Each group of Invoice Line Items represents the itemization of an INVOICE.  Each invoice line item represents a charge to an Enron customer. | Priority: High | JOB_KEY | The job which created the row
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | INVOICING_GROUP_KEY | The data warehouse's unique identifier for the INVOICING_GROUP
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | BILLING_CUSTOMER_KEY | The data warehouse's unique identifier for the BILLING_CUSTOMER
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | INVOICING_GROUP_NAME | The name of the INVOICING_GROUP
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's unique identifier for the INVOICING_GROUP
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM that created and/or updated the row
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | STREET_ADDRESS_1 | 1st row of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | STREET_ADDRESS_2 | 2nd row of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | CITY | The city of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | COUNTY | The county of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | STATE_KEY | The state of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | ZIP_5 | The 5 digit zip code of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | [NAME] | The 4 digit zip code suffix of the "bill to" address
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | JOB_KEY | The job that created the row
INVOICING_GROUP | The customer entity that is responsible for receiving the INVOICEs.  An INVOICE, which is sent to an INVOICING_GROUP, will represent the consumption of MASTER_SERVICEs by one or more USTOMER_ACCOUNTs. |  | UPDATE_JOB_KEY | The job that updated the row
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | JOB_KEY
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | JOB_NAME
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | DATA_START_DATE
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | DATA_END_DATE
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | JOB_START_DATE
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | JOB_END_DATE
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | RUN_STATUS
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | SOURCE_SYSTEM_KEY
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | UPDATE_JOB_KEY
JOB_TABLE | This table contains the master list of all data warehouse extract, transformation and load processes (ETLs)- JOB_NAME.  A JOB_KEY represents one execution of an ETL job.    By planting the JOB_KEY on each data warehouse table, allows for quick identification of which job created or updated any row in the data warehouse.   Every row in each data warehouse table will reference the job that created it by the JOB_KEY column.  Rows that can be upadated will reference the updating Job by the an UPDATE_JOB_KEY column. | When the team starts to load persistent data into the data warehouse (e.g. when the ETL is enhanced to load incremental data instead of a full-refresh in all cases), a RUN table will need to be added to the model.    A RUN will represent a grouping of JOBs run for the business in order to load data from specific SOURCE_SYSTEMs and subject areas over a time period. (e.g. [NAME] and STAT AR and AP data for the month of January 2002). The RUN will be the mechanism used to communicate to the business users what data has been loaded and when.  It will also be the mechanism used by the validation team to validated all data belonging to specific RUNS. | [NAME]
MASTER_SERVICE | The MASTER_SERVICE entity contains the list of commodity and non-commodity based services, which Enron offers its customer.  e.g. gas, power, sewage, garbage disposal, boiler maintenance, etc. |  | MASTER_SERVICE_KEY | The data warehouse's unique identifier of a MASTER_SERVICE
MASTER_SERVICE | The MASTER_SERVICE entity contains the list of commodity and non-commodity based services, which Enron offers its customer.  e.g. gas, power, sewage, garbage disposal, boiler maintenance, etc. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
MASTER_SERVICE | The MASTER_SERVICE entity contains the list of commodity and non-commodity based services, which Enron offers its customer.  e.g. gas, power, sewage, garbage disposal, boiler maintenance, etc. |  | MASTER_SERVICE_NAME | The name of the MASTER_SERVICE
MASTER_SERVICE | The MASTER_SERVICE entity contains the list of commodity and non-commodity based services, which Enron offers its customer.  e.g. gas, power, sewage, garbage disposal, boiler maintenance, etc. |  | JOB_KEY | The job which created the row
MASTER_SERVICE | The MASTER_SERVICE entity contains the list of commodity and non-commodity based services, which Enron offers its customer.  e.g. gas, power, sewage, garbage disposal, boiler maintenance, etc. |  | UPDATE_JOB_KEY | The job which update the row
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | [NAME] | The data warehouse's unique identifier of the account activity row
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM that creates and/or updates the row | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | GL_MONTH | The month on which the activity was posted in the AR subledger | This field will be loaded from the GL_PERIOD column in the source file.  It must be stored as a date datatype
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | OF_ACCOUNT_KEY | The subledger's financial account against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | SUPPLIER_KEY | The SUPPLIER against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | CUSTOMER_TYPE_KEY | The CUSTOMER_TYPE against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | STATE_KEY | The STATE against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | OF_LONG_ACCOUNT | The full OF ACCOUNT against which the activity was posted (includes seg1, seg2, seg3, seg4, seg5 and seg6) | This column is NOT yet supplied in the SOURCE_SYSTEM.  It has been requested in time for V6
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_NUM | MSAP's unique identifier for the SUPPLIER
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | PROFIT_CENTER | ?
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_NAME | The name of the SUPPLIER
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_ADDRESS_LINE1 | 1st row of the SUPPLIER's address
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | [NAME] | 1st row of the SUPPLIER's address
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_CITY | The city at which the SUPPLIER is located
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_STATE | The state at which the SUPPLIER is located
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VENDOR_ZIP_CODE | The zip code at which the SUPPLIER is located
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | DUE_DATE | The date by which the dollars must be paid by Enron to the SUPPLIER
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | FROMDATE | The first date on which the MASTER_SERVICE was consumed/realized (or first date of the bill-cycle).
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | TODATE | The last date on which the MASTER_SERVICE was consumed/realized (or last date of the bill-cycle).
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | VOLUME | The number of units of MASTER_SERVICE that was realized/consumed between the FROMDATE and TODATE
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | GAS_PURCHASE_VOLUME | ?
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | GP_UNIT_OF_MEASURE | ?
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | UNIT_OF_MEASURE | The unit of measure in which VOLUME is associated
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | PAY_AMOUNT | The total dollars owed by Enron to the SUPPLIER for consumption of a MASTER_SERVICE between the FROMDATE and TODATE.
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | SAP_GL_ACCOUNT | Holds the SAP GL account against which the activity in the row was posted | This column will be populated from the GL_ACCOUNT column in the MSAP file
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | [NAME] |  | The description of the SAP_GL_ACCOUNT
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | COMPANY |  | The SOURCE_SYSTEM from which the activity was sourced  Possible Values: '087C' = [NAME] '0890' = STAT
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | MSAP_IMPORT_DATE |  | The date on which MSAP imported the data from the billing system's extract file
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | REQUEST_DATE |  | The date on which the paper Payment Request  was received by the MSAP administrator  All payments to SUPPLIERs are submitted via extract files to MSAP and are submitted in a paper request form   The MSAP administrator must individually approve each utility file by comparing the paper requests to the data received.
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | SAP_UPLOAD_DATE |  | The date on which the data was loaded into SAP AP
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | STAT_ORDER |  | ?
MSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an MSAP GL_ACCOUNT (from MSAP's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AP Subledger. |  | ESTIMATED_SETTLEMENT_DATE |  | Estimated date on which Enron will pay the SUPPLIER
MSAPSTATE_TO_RANGERSTATE | This table is used to translate MSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | MSAP_COMPANY
MSAPSTATE_TO_RANGERSTATE | This table is used to translate MSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | MSAP_VENDOR_STATE
MSAPSTATE_TO_RANGERSTATE | This table is used to translate MSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_STATE_KEY
MSAPSTATE_TO_RANGERSTATE | This table is used to translate MSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_STATE_NAME
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | MSAP_COMPANY
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | MSAP_VENDOR_NUM
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | MSAP_VENDOR_NAME
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_SUPPLIER_SOURCE_SYSTEM_ID
MSAPUDC_TO_RANGERUDC | This table is used to translate MSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SOURCE_SYSTEM
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG1
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG5
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG5DESC
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_MASTER_SERVICE_KEY
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_CUSTTYPE_SYSTEM_KEY
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_CUSTTYPE_SOURCE_SYSTEM_ID
OFCUSTTYPE_TO_RANGERRCUSTTYPE | This table is used to translate OFSAP's identification of a CUSTOMER_TYPE to Ranger's CUSTOMER_TYPE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
OFMARKET_TO_SOURCE_SYSTEM | This table is used to associate an OFSAP_ACCOUNT_ACTIVITY_FACT to a RANGER SOURCE_SYSTEM_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG1
OFMARKET_TO_SOURCE_SYSTEM | This table is used to associate an OFSAP_ACCOUNT_ACTIVITY_FACT to a RANGER SOURCE_SYSTEM_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG4
OFMARKET_TO_SOURCE_SYSTEM | This table is used to associate an OFSAP_ACCOUNT_ACTIVITY_FACT to a RANGER SOURCE_SYSTEM_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_OFSEG3
OFMARKET_TO_SOURCE_SYSTEM | This table is used to associate an OFSAP_ACCOUNT_ACTIVITY_FACT to a RANGER SOURCE_SYSTEM_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | OFSAP_ACCOUNT_ACTIVITY_KEY | The data warehouse's unique identifier of the account activity row
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM that creates and/or updates the row | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | GL_MONTH | The month on which the activity was posted in the AR subledger | This field will be loaded from the GL_PERIOD column in the source file.  It must be stored as a date datatype
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | OF_ACCOUNT_KEY | The subledger's financial account against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SUPPLIER_KEY | The SUPPLIER against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | CUSTOMER_TYPE_KEY | The CUSTOMER_TYPE against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | STATE_KEY | The STATE against which the activity was posted | This column is NOT available in the SOURCE_SYSTEM.  It references the dimension table  It will be populated in v7 via the translation tables
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | OF_LONG_ACCOUNT | The full OF ACCOUNT against which the activity was posted (includes seg1, seg2, seg3, seg4, seg5 and seg6) | This column is NOT directly supplied in the SOURCE_SYSTEM.  It must be populated with the concatenation of seg1 through seg6.
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG1 | Company segment  Possible Values: 01 = Gas EESO 02 = Power EESO 03 = Non-Commodity EESO 05 = Gas [NAME] 06 = Power [NAME] 07 = [NAME]
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG2 | Oracle Financials Natural Account (4 digit)  e.g. Power Sales, Gas Sales, LDC-Passthrough charges, Energy Resources Surcharge, etc.
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG2DESC | Natural account description
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG3 | State against which the activity was posted
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG3DESC | State description
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG4 | LDC against which the activity was posted
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG4DESC | LDC description
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG5 | CUSTOMER_TYPE or Market Segment (what OF calls the CUSTOMER_TYPE  Possible Values: 000 Unidentified 001 Not Used 002 Not Used 003 Don't Use  100 Industrial 200 Commercial 300 Residential 400 Government 500 Intercompany
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG5DESC | CUSTOMER_TYPE description
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG6 | Commodity  Possible Value: 000 Unidentified 001 Unspecified 008 General Cable Corp 009 General Service Administr 024 World Color Press, Inc. 027 Simon Properties  100 Gas 200 **Electric-commodity 300 Non-commodity
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | SEG6DESC | Commodity Description
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | CURRENCY |  | The currency in which the dollar activity is associated
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | BEG_BAL |  | The starting dollar balance in the OF account at the begining of the GL_PERIOD
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | END_BAL |  | The starting dollar balance in the OF account at the begining of the GL_PERIOD
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | PERIOD_BAL_CHG |  | The dollar activity posted against the OF account over the GL_PERIOD
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | YTD_BAL_CHG |  | The dollar activity posted against the OF account over the entire year
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | BEG_VOL |  | The starting volume balance in the OF account at the begining of the GL_PERIOD
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | END_VOL |  | The ending volume balance in the OF account at the begining of the GL_PERIOD
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | PERIOD_VOL_CHG |  | The volume activity posted against the OF account over the entire year
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | YTD_VOL_CHG |  | The volume activity posted against the OF account over the entire year
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | DTH_BEG_VOL |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | DTH_END_VOL |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | DTH_PERIOD_VOL_CHG |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | [NAME] |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | OF_UOM |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | CONV_UOM |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | VOLS_CONVERTED |  | ?
OFSAP_ACCOUNT_ACTIVITY_FACT | This fact contains each GL Month's accounting activity associated with an Oracle Financials GL_ACCOUNT (from Oracle Financial's perspective).    Ultimately, data in this fact is used to validate that the billing SOURCE_SYSTEM reconciles with the AR Subledger. |  | CONVERSION_RATE |  | ?
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SOURCE_SYSTEM
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG1
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG3
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG3DESC
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_MASTER_SERVICE_KEY
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_STATE_SYSTEM_KEY
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_STATE_KEY
OFSTATE_TO_RANGERSTATE | This table is used to translate OFSAP's identification of a STATE to Ranger's STATE_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_STATE_NAME
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SOURCE_SYSTEM
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG1
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_SEG4DESC
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | OF_DESC
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_MASTER_SERVICE_KEY
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | RGR_SUPPLIER_SOURCE_SYSTEM_ID
OFUDC_TO_RANGERUDC | This table is used to translate OFSAP's identification of a SUPPLIER to Ranger's SUPPLIER_KEY.    It is used during the process of reconciling the billing SOURCE_SYSTEM to the subledger. |  | [NAME]
PHYSICAL_INDICATOR | Indicates whether Enron is physically responsible for providing the MASTER_SERVICE (e.g. commodity). |  | PHYSICAL_INDICATOR_KEY | The data warehouse's code indicating whether Enron is responsible for delivering the MASTER_SERVICE
PHYSICAL_INDICATOR | Indicates whether Enron is physically responsible for providing the MASTER_SERVICE (e.g. commodity). |  | PHYSICAL_INDICATOR_DESCRIPTION | A description of the PHYSICAL_INDICATOR
PHYSICAL_INDICATOR | Indicates whether Enron is physically responsible for providing the MASTER_SERVICE (e.g. commodity). |  | JOB_KEY | The job which created the row
PHYSICAL_INDICATOR | Indicates whether Enron is physically responsible for providing the MASTER_SERVICE (e.g. commodity). |  | UPDATE_JOB_KEY | The job which updated the row
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | PHYSICAL_LOCATION_KEY | The data warehouse's unique identifier for a BILLING_CUSTOMER's PHYSICAL_LOCATION
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | BILLING_CUSTOMER_KEY | The data warehouse's unique identifier for the BILLING_CUSTOMER
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM that created and/or updated the row
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's unique identifier for a PHYSICAL_LOCATION
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | PHYSICAL_LOCATION_NAME | The name of the PHYSICAL_LOCATION
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | STREET_ADDRESS_1 | 1st line of the PHYSICAL_LOCATION's street address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | STREET_ADDRESS_2 | 2nd line of the PHYSICAL_LOCATION's street address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | CITY | The city of the PHYSICAL_LOCATION's address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | COUNTY | The county of the PHYSICAL_LOCATION's address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | STATE_KEY | The state of the PHYSICAL_LOCATION's address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | ZIP_5 | The 5-digit zip code of the PHYSICAL_LOCATION's address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | [NAME] | The 4-digit zip code suffix of the PHYSICAL_LOCATION's address
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | EFFECTIVE_DATE | The EFFECTIVE_DATE & TERMINATION_DATEs are used to track history on a PHYSICAL_LOCATION.    When a field, on which history is being tracked, changes a new row is created in the PHYSICAL_LOCATION table containing the new state of the field.  The first rows' TERMINATION_DATE will be set to one day prior to the EFFECTIVE_DATE of the new row.
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | TERMINATION_DATE | The EFFECTIVE_DATE & TERMINATION_DATEs are used to track history on a PHYSICAL_LOCATION.    When a field, on which history is being tracked, changes a new row is created in the PHYSICAL_LOCATION table containing the new state of the field.  The first rows' TERMINATION_DATE will be set to one day prior to the EFFECTIVE_DATE of the new row.
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | JOB_KEY | The job which created this row
PHYSICAL_LOCATION | A BILLING_CUSTOMER's physical premse that receives one or more MASTER_SERVICEs. | History tracking will be implemented in V6 of the data model.  Additionally, a new column will need to be added to store the data warehouse's unique identifier for the PHYSICAL_LOCATION.  This will be required because once history is supported, each row in the PHYSICAL_LOCATION dimension (and hence the PHYSICAL_LOCATION_KEY) will represent a snapshot of a PHYSICAL_LOCATION over a period of time.  The data warehouse identifier will be required to "tie" the snapshots together. | UPDATE_JOB_KEY | The job which updated the row
PRODUCT | Represents a pricing arrangement under which a MASTER_SERVICE will be paid for.  e.g. flat rate, fixed, % off commodity, % of tariff, index (electric = Dow, gas = Nimex), % off frozen, cents off, tiered/step, overtake/undertake, interval, seasonal, blended/custom. |  | PRODUCT_KEY | The data warehouse's unique identifier of the PRODUCT
PRODUCT | Represents a pricing arrangement under which a MASTER_SERVICE will be paid for.  e.g. flat rate, fixed, % off commodity, % of tariff, index (electric = Dow, gas = Nimex), % off frozen, cents off, tiered/step, overtake/undertake, interval, seasonal, blended/custom. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
PRODUCT | Represents a pricing arrangement under which a MASTER_SERVICE will be paid for.  e.g. flat rate, fixed, % off commodity, % of tariff, index (electric = Dow, gas = Nimex), % off frozen, cents off, tiered/step, overtake/undertake, interval, seasonal, blended/custom. |  | PRODUCT_NAME | The name of the PRODUCT
PRODUCT | Represents a pricing arrangement under which a MASTER_SERVICE will be paid for.  e.g. flat rate, fixed, % off commodity, % of tariff, index (electric = Dow, gas = Nimex), % off frozen, cents off, tiered/step, overtake/undertake, interval, seasonal, blended/custom. |  | JOB_KEY | The job which created the row
PRODUCT | Represents a pricing arrangement under which a MASTER_SERVICE will be paid for.  e.g. flat rate, fixed, % off commodity, % of tariff, index (electric = Dow, gas = Nimex), % off frozen, cents off, tiered/step, overtake/undertake, interval, seasonal, blended/custom. |  | UPDATE_JOB_KEY | The job which updated the row
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | RATE_SCHEDULE_KEY | The data warehouse's unique identifier for a RATE_SCHEDULE
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM'S identifier of the RATE_SCHEDULE
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | RATE_SCHEDULE_DESCRIPTION | The description of the RATE_SCHEDULE
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | JOB_KEY | The job which created the row
[NAME] | A rate schedule identifies the schedule which defines the prices paid for consumption per time period (e.g. non-peak intervals, peak intervals, etc). |  | UPDATE_JOB_KEY | The job which updated the row
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | SERVICE_STATUS_KEY | The data warehouse's unique key indicating a status condition
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM which created and/or updated the row
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's unique code for the SERVICE_STATUS
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | SERVICE_STATUS_DESCRIPTION | The description of the SERVICE_STATUS
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | JOB_KEY | The job which created the row
SERVICE_STATUS | Identifies whether a CUSTOMER_ACCOUNT is active, inactive, etc. |  | UPDATE_JOB_KEY | The job which updated the row
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | SOURCE_SYSTEM_KEY
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | SOURCE_SYSTEM_NUMBER
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | SOURCE_SYSTEM_STRING
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | SOURCE_SYSTEM_DESCRIPTION
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | DATAWAREHOUSE_FIELD_NAME
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | DATAWAREHOUSE_KEY
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | DATEWAREHOUSE_DESCRIPTION
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | EFFECTIVE_DATE
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | TERMINATION_DATE
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | JOB_KEY
SOURCE_CODE_TRANSLATION | This table is used to support commonization of SOURCE_SYSTEM codes, types and status's.  SOURCE_SYSTEM codes will be commonized via translations to predefined data warehouse target values (DATAWAREHOUSE_KEY) n the SOURCE_CODE_TRANSLATION table. | One of the main focuses of V7 will be using this table to commonize codes, types, and status's.  Until V7, this table will only be used lightly and on an as-needed basis. | UPDATE_JOB_KEY
SOURCE_SYSTEM | A system from which data in the data warehouse was sourced.  e.g. STAT, [NAME], ALTRA, HP National, HP CA, HP COH, HP Power, OFSAP, MSAP, etc. |  | SOURCE_SYSTEM_KEY | The data warehouse's unique identifier of a SOURCE_SYSTEM.
SOURCE_SYSTEM | A system from which data in the data warehouse was sourced.  e.g. STAT, [NAME], ALTRA, HP National, HP CA, HP COH, HP Power, OFSAP, MSAP, etc. |  | SOURCE_SYSTEM_NAME | The name of the source system (ie STAT, [NAME], etc)
SOURCE_SYSTEM | A system from which data in the data warehouse was sourced.  e.g. STAT, [NAME], ALTRA, HP National, HP CA, HP COH, HP Power, OFSAP, MSAP, etc. |  | JOB_KEY | Job that created the row.
SOURCE_SYSTEM | A system from which data in the data warehouse was sourced.  e.g. STAT, [NAME], ALTRA, HP National, HP CA, HP COH, HP Power, OFSAP, MSAP, etc. |  | UPDATE_JOB_KEY | Job that updated the row
STATE | A STATE is a Geographical region within a COUNTRY. |  | STATE_KEY
STATE | A STATE is a Geographical region within a COUNTRY. |  | [NAME]
STATE | A STATE is a Geographical region within a COUNTRY. |  | STATE_ABBREVIATION
STATREADFLAG |  |  | STATUS
STATREADFLAG |  |  | TMSTAMP
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | SUPPLIER_KEY | The data warehouse unique identifier for a SUPPLIER.
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | SUPPLIER_TYPE_KEY | System generated key representing a type of SUPPLIER.    Possible Values: 0 = 'Unknown' 1 = 'UDC'
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | SOURCE_SYSTEM_KEY | The SOURCE_SYSTEM from which this row was created and/or updated
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | SOURCE_SYSTEM_ID | The SOURCE_SYSTEM's identifier for the SUPPLIER.  (ie, STAT's id for a given utility)
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | SUPPLIER_NAME | The name of the SUPPLIER.
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | DUNS_NUMBER | The number that identifies each utility company.
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | JOB_KEY | The job which created the row
SUPPLIER | This will contain all of the providers of MASTER_SERVICEs from the Enron perspective.  This includes Utility Distribution Companies that transmit and distribute a commodity to a BILLING_CUSTOMER'S PHYSICAL_LOCATION. |  | UPDATE_JOB_KEY | The job which updated the row
SUPPLIER_TYPE | During iteration 1, UDC will be the only valid SUPPLIER_TYPE. |  | SUPPLIER_TYPE_KEY | System generated key representing a type of SUPPLIER.    Possible Values: 0 = 'Unknown' 1 = 'UDC'
SUPPLIER_TYPE | During iteration 1, UDC will be the only valid SUPPLIER_TYPE. |  | SUPPLIER_TYPE_NAME | The name of the SUPPLIER_TYPE.  e.g. Unknown, UDC, etc.
SUPPLIER_TYPE | During iteration 1, UDC will be the only valid SUPPLIER_TYPE. |  | JOB_KEY | The job that created the row
SUPPLIER_TYPE | During iteration 1, UDC will be the only valid SUPPLIER_TYPE. |  | UPDATE_JOB_KEY | The job that updated the row