Month: September 2011

The "FERC Response" Field

A Filed Tariff Record Version (FTRV) can be thought of as a proposal to FERC to affect a change in one’s tariff.  The status of such a change is called the “FERC Response”.  FERC Response, therefore, is a very important FTRV field.  TariffShark supports several FERC Response values.  Presented alphabetically below, this blog article defines all of TariffShark’s FERC Response values.


An FTRV that has been approved by FERC but cannot yet be considered Effective.

Approved Subject to Conditions

An FTRV that has been approved by FERC as long as certain changes are made and the TRV is refiled.


A Draft FTRV is one that is being worked on and has, therefore, not yet been filed with FERC. All details associated with a Draft FTRV and its underlying TRV, including its content, may be updated. A Draft FTRV and its underlying TRV may also be deleted.


An FTRV that has been filed with and approved by FERC is designated Effective when it is to be considered part of an effective Tariff. For example, when two related FTRVs have been filed with FERC and only one was approved, it might not make sense to mark either of them Effective until both have been approved.

Overtaken by Events

An FTRV that has been filed with FERC but has been subsequently replaced by a more recently filed FTRV. For example, if you filed Rate Schedules v3.0.0 and realized a week later that textual changes were missed and needed to be filed as a correction, upon filing and FERC accepting Rate Schedules v4.0.0 in an amendment filing, Rate Schedules v3.0.0 is considered to be “Overtaken by Events”.


An FTRV that has been filed with FERC and on which FERC has not yet acted (either through the issuance of an order or by the tolling of the statutory clock).

Pro Forma Ordered

When a Pro Forma FTRV is submitted to FERC it does not represent a true proposal before the commission. Therefore, many of the FTRV FERC Response values presented here do not apply. So that a Pro Forma FTRV doesn’t remain “Pending” forever, assign a FERC Response of “Pro Forma Ordered” after FERC has issued an order in response to a Pro Forma submission.


An FTRV that has been rejected by FERC order.


At your discretion, you may change an FTRV’s status to Retired when it is no longer in effect. This is not necessary, however, since TariffShark knows which TRV is in effect when several versions of the same Tariff Record are all Effective. For example, given the following Effective FTRVs:
  • “Rate Schedules” v0.0.0, effective 4/1/2010
  • “Rate Schedules” v1.0.0, effective 5/1/2010
  • “Rate Schedules” v2.0.0, effective 6/1/2010
TariffShark knows that “Rate Schedules” v1.0.0 is the one that is in effect on 5/15/2010 and that “Rate Schedules” v2.0.0 is in effect on 9/1/2010.


An FTRV that has been suspended by FERC order.


An FTRV that was filed with FERC but was subsequently withdrawn prior to FERC action.

When assigning a FERC Response value to an FTRV, the valid values for a given situation depend upon the FTRV’s Record Change Type.  For example, it is not possible to assign a FERC Response of “Effective” to an FTRV that was submitted to FERC with a Record Change Type of “Pro Forma” (because Pro Forma requests are not official proposals before the commission).  You needn’t worry about which FERC Response values are valid and which ones are not: TariffShark will only provide you with valid choices.

If you have questions about FERC Response, we’d love to hear from you.  Please comment below or contact TariffShark Support.

Moving or Copying a TariffShark Database

[Updated July 10, 2017]

Sometimes it is necessary to move or copy a TariffShark database from one server to another.  You might need to do this if you’re setting up a new production environment or refreshing a test environment with current production data.  This blog article describes the best practice procedure for cloning a TariffShark database.

  1. Backup the database you are copying using the SQL Server utility for this purpose.
  2. Restore the database to a different SQL Server Instance and/or different database, again, using the SQL Server utility for this purpose.
  3. If you are updating an existing test environment with a fresh set of production data, you may wish to preserve the client registrations in the test database.  Doing so will enable desktop TariffShark users who have previously accessed the test database to login after the database restore without having to re-register their software client.  To preserve the client registrations in the test database, (a) make a backup copy of the SoftwareClient table in the test database before restoring the database and (b) restore the SoftwareClient table afterward.
  4. The Audit table tracks web service method calls and responses for a TariffShark application server (which is done strictly for debugging reasons).  When establishing a new database, this data has little meaning when copied from another database.  As an optional step you may choose to TRUNCATE the Audit table.
  5. The Relationships table must be rebuilt in the restored database.  Run the following script statements in order to do this:
    USE […Name of the TariffShark Database…]
    EXEC admin.RebuildRelationships
  6. TariffShark Tiger is able to distinguish PROD environments from TEST ones.  If you are still running TariffShark Hammerhead or haven’t made such a distinction, you may disregard this step.  On the other hand, in a TariffShark Tiger installation where PROD and TEST environments have been distinguished as such, your TEST environment will look like a PROD environment after the database restore.  In order to restore your TEST environment to “test” status, open a web browser and enter the following URL into the address bar:

If you ever need to restore a TariffShark database, follow the procedure outlined above.  If you would like to know more about TariffShark databases or if you have any other questions, please comment below or contact TariffShark Support.

eTariff FTRV Level Associations

FERC’s eTariff rules allow you to associate a tariff record you are submitting with a previously filed tariff record.  In TariffShark terms, a Filed Tariff Record Version (FTRV) you are preparing to submit may be associated with an FTRV from an earlier Filing.  This article will explain why you might want to associate two FTRVs and how to do this in TariffShark.

An FTRV association tells FERC (a) to ignore the earlier-filed FTRV as you are no longer proposing that TRV for consideration and (b) to use the latter-filed one as a replacement proposal.  Upon OSEC acceptance of the second FTRV, FERC assigns a status of OBE (overtaken by events) to the first one (if it is still pending before the Commission).  The most common scenario where it would be appropriate to associate one FTRV with another is when filing a corrected FTRV (generally done in an amendment-type filing).  In this situation, the latter-filed FTRV is clearly a replacement for the earlier-filed one.

In TariffShark, associating an FTRV with another one can be done easily from the Update Filed Tariff Record Version screen.

  1. Open the Filing Details screen for the Filing you are preparing to submit to FERC.
  2. On the Tariff Record Versions tab, select the desired FTRV and click the Update FTRV command in the SmartBar (shown below), which will open the Update Filed Tariff Record Version screen.
  3. On the Update Filed Tariff Record Version screen, click the ellipsis button next to the Associated With field (shown below) to select an earlier-filed FTRV to which an association should be made.
  4. In the resulting pop-up form (shown below), (a) select the earlier Filing, (b) then select the earlier-filed FTRV in the grid, and (c) then click the Select button.
  5. Back on the Update Filed Tariff Record Version screen, click the Update button.

TariffShark Validations

Seems easy enough, right?  Well, the vanilla case described above is pretty straightforward.  However, there are more complex scenarios where it may or may not be appropriate to make an FTRV level association.  TariffShark does not pretend to understand all of the regulatory nuances surrounding the filing of tariff records.  Instead, it issues validation warnings in order to make you aware of opportunities to associate FTRVs and allows you to decide if it’s appropriate or not.

There are several validations in TariffShark that relate to FTRV level associations and most of these are very specific.  However, detailed below are the general purpose warnings.  Note that FTRV FERC Response (which describes the status of an FTRV) plays a big part in these validations.  Therefore, it is very important that you keep your FTRV FERC Response values accurately updated.

Validation R045

Filed Tariff Record Version (FTRV) “” is associated with another FTRV whose FERC Response is “Pending”. If the associated record has a status of “Pending” at FERC, submitting this Filing will cause the associated record’s status in the eTariff Viewer to become OBE (overtaken by events). Proceed with caution as this may not be what you intend.

Explanation of R045

If you have associated an FTRV with a Pending FTRV, this message appears.  In the vanilla case where you are submitting an amended FTRV, you would expect to see this validation warning.

Validation R046

Filed Tariff Record Version (FTRV) “” is not associated with another FTRV, yet one or more “Pending” FTRVs exist. If you intend to submit this FTRV as a replacement for one of the pending FTRVs, then you must associate this FTRV with the one you wish to replace.

Explanation of R046

If you have not associated an FTRV with another FTRV and one or more Pending FTRVs are present, this message appears.

Validation R047

[1] Filed Tariff Record Version (FTRV) “” is associated with another FTRV. [2] Tariff Record “” has child Tariff Records. Submitting this Filing will cause the associated record to become moot and its status in the eTariff Viewer to become OBE (overtaken by events). This automatic update in FERC’s software cascades to child Tariff Records also pending at FERC from earlier Filings. Under certain circumstances, this causes the child records to disappear…as if they hadn’t been filed. Proceed with caution!

Explanation of R047

The disappearance of child tariff records in FERC’s system happened to a TariffShark customer in 2010 after submitting a baseline eTariff filing followed shortly thereafter by a subsequent filing.  A complex combination of circumstances caused the child tariff records to disappear and such circumstances are not likely to be reproduced.  All the same, we felt it was prudent for TariffShark to warn eTariff filers of the potential issue.

If you would like to know more about FTRV-level associations or if you have any other questions, please comment below or contact TariffShark Support.