Administration

My Operator

• only shown to external users, who can only be associated with one operator per user account
• displays current data known about the operator

Partner Company

If an operator's business structure is a General Partnership, the operator can have 1 or multiple partners. For each partner company, the partner's CRA Business Number and BC Corporate Registry Number will be collected.

Parent Company

An operator can have 0, 1, or multiple parent companies. The parent compan(y)/(ies) may or may not be located inside Canada. If the parent company is within Canada, the CRA Business Number must be collected. If the parent company is outside Canada, a more generic "Tax ID Number" should be collected, and the address field is a freeform text field rather than broken down into explicit fields for municipality, province, postal code, etc.

Operations

• an operator can have a maximum of 1 Linear Facility Operation (LFO) assigned to them. They may have zero LFOs
• an operator can have 1 or more Single Facility Operations (SFOs) assigned to them, or they may have zero SFOs

Operation Status

• Registered: an external user acting on behalf of their operator has completed the form to register the operation. A status of "Registered" doesn't necessarily indicate that IRC has issued a BORO ID or BCGHG ID to the operation
• Transferred: the operation previously belonged to the operator, but has since been reassigned to another operator. Operators need access to their historical operations for Reporting purposes. The new operator will see this transferred operation with a status of "Registered"
• Temporarily Shutdown: the operation has been marked as Temporarily Shutdown using the "Report an Event" workflow, and no corresponding Restart event has been created for the operation at the present time
• Closed: a Closure event has been reported for the operation. No corresponding Restart event has been created for the operation at the present time
• Draft: partial data for the operation exists in the BCIERS database, but no external user acting on behalf of the operator has yet submitted the complete registration form data. This status also applies to operations that were either imported from SWRS or newly created under Registration 1, until the operator updates the operation data and officially submits the registration form.
• an operation that was previously Closed or Temporarily Shutdown and then subsequently Restarted will have a status of Registered by default (unless other conditions exist, i.e., it's been transferred)

BORO ID

• granted only to operations
• the BORO ID is auto-generated by BCIERS, but is only issued to a registered operation upon an internal user manually confirming (button click) that a BORO ID should be granted to the operation
• format yy-nnnn where yy indicates the year that the BORO ID was issued in, and nnnn is a 4-digit number generated sequentially. At the start of each calendar year, nnnn resets to 0001

BCGHG ID

• granted to operations. An SFO will have one BCGHG ID in total. An LFO will have one BCGHG ID per facility, and an additional BCGHG ID for the operation as a whole.
• see BCGHG ID below for further details

Facilities

• facilities are always tied to a specific operation
• a facility may have a BCGHG issued to it

BCGHG ID

• granted to each facility within an LFO
• auto-generated by BCIERS, but is only issued when an internal user manually confirms (by button click) that a new BCGHG ID should be created for the selected facility
• format: 11-digit number constructed as {o}{cccccc}{nnnn} where {o} is 1 for LFOs or 2 for SFOs, {cccccc} is the NAICS code applicable to the facility, and {nnnn} is a 4-digit number generated sequentially based on the 7-digit number preceding it, starting from 0001
• Example: 12212100001 indicates a facility belonging to an LFO with NAICS code 221210, and it was the first facility of that (operation type, NAICS code) combo. A subsequent facility that also belongs to an LFO and has a NAICS code of 221210 would be issued the BCGHG ID '12212100002'. A new facility with the same NAICS code but belonging to an SFO would therefore be issued the ID '22212100001'.

Contacts

A "Contact" is a generic term for a person who works for an operator. They may or may not be a BCIERS user. A contact can be assigned zero-to-many roles within BCIERS across modules. A contact can be soft-deleted from BCIERS (for example, if they no longer work for the operator) but before deletion, they must be unassigned from all places where they have been assigned a role. This could mean that another contact needs to be assigned as their replacement.

Registration

• Operation Representative - assigned at the operation level. An operation must have at least 1 assigned Operation Representative, but can have multiple assigned at the same time

Reporting

• Person Responsible for Reporting - assigned for each emissions report (per operation, per reporting year)

COAM

• Primary Account Representative
• Secondary Account Representative

User Access Requests

• lists all external users associated with the relevant operator
• users with the app role of "industry_admin" can manage industry user access levels, including declining an access request (so that the requestor has no permissions for the operator at all), assigning the role of "reporter" (has access to everything except User Access Requests), or the role of "admin" (has access to everything).
• standard procedure is that internal users approve the first user access request for a SWRS-imported operator (who will automatically receive admin rights), and then all subsequent requests to access that operator should be managed by the operator's admin/s (assigning roles of reporter or admin; removing access rights entirely). Industry admins cannot remove their own access, so an operator should always have at least 1 admin. However, in cases where an operator is locked out because their only admin has left the company, internal users can also access user requests for an operator to assign someone new as admin.
• note that the roles assigned to a user are entirely separate from the roles assigned to a contact
• internal users with the "cas_admin" role can manage access requests from other users with IDIRs.

Report an Event

Per GGERR, all operators are expected to report to BCIERS any of the following events within 30 days of their occurrence.

Closures, Temporary Shutdowns, & Restarts

not yet implemented

• can apply to either an entire operation or to one or more facilities within an operation. If multiple facilities are selected, they must all be within the same LFO
• in the database, events have separate columns for operation ID and facility IDs. Only one of these fields will ever be populated, indicating whether the event is at the operation-level or the facility-level
• each event type has a separate form and is expected to be filled out by the external user only - no action is required by IRC staff, although they can view the data submitted in these forms from all operators
• in order for a Restart event to be created, there must first be a corresponding Temporary Shutdown or Closure event

Transfers

• can apply to either an entire operation or to one or more facilities within an operation. If multiple facilities are selected, they must all be within the same LFO
• if operation is being transferred, the assigned BORO ID for the operation will also be transferred over to the receiving operator

Current Process:

• industry user emails GHG Regulator to inform them of a transfer. Once all details about the transfer have been confirmed, an internal user (either cas_admin or cas_analyst) creates a new Transfer in the UI, including the "effective date" of the transfer.
• if the effective date of the transfer is in the past, the transfer will take effect immediately. Otherwise, a cron job runs daily in Openshift that checks for pending transfers that should be implemented (i.e., the effective date matches today's date)
• once a transfer has been completed, the new operator will see the transferred operation/facility in their Admin module, and the old operator won't see it at all. However, the old operator should still see partial data for their transferred operations/facilities in the Reporting module.

Envisioned Future Process:

• guidance that IRC will be circulating to external users is that both operators involved in a transfer are expected to submit a transfer form (i.e., there will be 2 forms submitted for each transfer event)
• operators submit transfer form to request the transfer of an entity. IRC staff review the data submitted in the forms, then fill out an additional form either confirming which facilities/operations are to be transferred, or "completing" (i.e., not transferring) the entities
• if an entire LFO is being transferred to another operator, the external users only need to select the operation being transferred, not the individual facilities within the LFO
• an operator is only permitted to have a maximum of 1 LFO, so if a facility is being transferred to another operator, the receiving operation can be inferred based on the operator receiving the facility