EMTS System Changes

I.   Introduction

    Several changes are scheduled for EMTS during the fourth quarter of 2011. Most of these changes
    involve data reporting field name changes, new non-required fields, minimum lengths for fields, and
    the reordering of fields. In addition, there is one new required field for separate and retire
    transactions.

    This document describes each of the changes and then outlines the effects of the changes on three
    groups of users: 1) EMTS Node users; 2) EMTS Conversion Tool (ECT) users; and 3) EMTS Web
    interface users. Users will need to modify the way they currently interact with EMTS in response to
    these system changes.

II.   List of Changes

    The upcoming EMTS system changes are related to the XML Schema Document (XSD). The XSD is
    the underlying structure for organizing XML transaction data reported through both the EMTS web
    interface and the EMTS node.

    The following XSD changes will be implemented (see Appendix A for more information):

       1.  A transaction date will be required for Separate and Retire transactions. The data element
          name will be "TransactionDate," which has always been required for the other types of
          transactions. See Number 2  below for changes to the Buy and Sell transaction date element.

       2.  In Buy and Sell transactions, the "Transaction Date" will be  referred to as the "Transfer
          Date."  The new data element name will be "TransferDate."

       3.  The element "FeedstockVolume" will be renamed to "FeedstockQuantity."  This will only
          affect generate transactions.

       4.  Seven new, non-required reporting elements will be created to add functionality for users:

          a)  MatchingTransactionldentifier

              This element will  allow users to accept specific  buy/sell transactions in the case of
              several similar transactions. It is a unique identifier assigned by EMTS to an initiated
              trade.  When  accepting a trade, users will be able to include this element in the trade
              matching criteria (along with the other trade matching  criteria currently in effect).  If
              this element is reported, EMTS will attempt to locate a  matching transaction based on
              the MatchedTransactionldentifier. If a match is not found, then the transaction will fail.
              If this element is not reported, then it will not be used in the trade matching (but all
              other required matching elements will still apply).
vvEPA
United States                                                EPA-420-B-11-031
Environmental Protection
Agency                                                         August 2011

-------
              NOTE: This element only applies to users that submit transactions via XML files.

          b)  SupportingDocumentDetail
          c)  SupportingDocumentText
          d)  SupportingDocumentNumberText

              The Supporting Document elements above will be added to Generate transactions.
              These elements have always been available for the other types of transactions.
              Supporting Document elements allow organizations to track transactions based on
              internal documentation, such as invoices, BOLs, etc.

          e)  PublicSupportingDocumen tDetail
          f)  SupportingDocumentText
          g)  SupportingDocumentNumberText

              This complex type PublicSupportingDocumentDetail contains the elements
              SupportingDocumentText and SupportingDocumentNumberText. These fields will allow
              users to create unique supporting document text that can be viewed by both trading
              parties in buy and sell transactions.

       5.  The following elements will have a minimum length (i.e, they cannot be blank) to prevent
          users from omitting these data elements from XML files:

              •  AssignmentCode
              •  ReasonCode (i.e, BuyReasonCode, SellReasonCode, SeparateReasonCode and
                 RetireReasonCode)
              •  FuelTypeCode
              •  ComplianceLevelCode

          NOTE:  Previously, these elements were checked during submission processing by EMTS. In
          the future, the file will fail XML validation and not reach EMTS if these elements are blank.

       6.  The following elements will be reordered for consistency across all complex transactions:

              •  SeparateReasonCode will be moved below RINYear; and
              •  GenerateTransactionDetail will be reordered to match the other transaction types.

III. EMTS Nodes

   Organizations that use  nodes to send and receive data in EMTS will need to update their internal
   processes for creating and validating XML files to accommodate the changes listed in Section 2 of
   this document. When the changes are implemented in EMTS, node users  should perform the
   following steps:

-------
    1)  Obtain the revised XSD:  EMTS-Schema-2.0.zip

    2)  Implement the revised XSD.

    3)  Generate XML files based on the revised XSD.

    4)  Validate the XML files using one of these methods:

       •   EPA's XML Schema Validation Tool, a web-based validation tool that utilizes a set of XML
           web services to validate XML files against the associated schemas and custom rules, located
           at http://tools.epacdxnode.net/.

       •   A third party XML validation tool that ensures XML files are both well-formed and valid
           according to the EMTS schema specifications.

    5) Test the XML file submission in the CDX Test and EMTS Testing environments.

IV.  EMTS Conversion Tool (ECT)

    The ECT is a tool that was created by EPA to convert Excel file templates into XML files to submit to
    EMTS. ECT users can input RIN transaction data into Excel files rather than using the EMTS web
    interface to create transactions. The ECT will be updated to include the upcoming changes to EMTS.
    The Excel templates for data input and the XML files generated by the ECT will include the changes
    listed in Section 2 of this document.

    NOTE: Once the upcoming EMTS changes have been implemented, files that are created using
    previous versions of the ECT will no longer be accepted by EMTS.

V.  EMTS Web Interface
       The EMTS web interface will be updated to include the changes listed in Section 2 of this
       document. Users will see the element name changes on the web forms, drop-down menus and
       EMTS reports

-------
             Appendix A
List of Proposed EMTS System Changes
Type of Change
New required element
Changed name of required
element
New non-required element
New Element Name
TransactionDate
TransferDate
FeedstockQuantity
MatchingTransaction
Identifier
SupportingDocument
Detail
SupportingDocument
Text
SupportingDocument
NumberText
PublicSupporting
DocumentText
Old Element Name
N/A
TransactionDate
FeedstockVolume
N/A
N/A
N/A
N/A
N/A
Type of
Transaction(
s) Affected
Separate
Retire
Buy
Sell
Generate
Buy
Sell
Generate
Generate
Generate
Buy
Sell
Required
Reporting
Element?
Yes
Yes
Yes
No
No
No
No
No
Description of Change
A transaction date is now required for
Separate and Retire transactions. This
element has always been required for the
other types of transactions; see below for
changes related to Buy/Sell transactions.
In Buy and Sell transactions only, the
Transaction Date will now be referred to as
the Transfer Date.
Feedstock Quantity is now referred to as
FeedstockVolume.
This element was added to allow users to
match trades on Transaction Identifiers
(additional matching criteria).
Supporting Document elements have been
added to Generate transactions. These
elements have always been available for the
other types of transactions. Supporting
Document elements allow organizations to
track transactions based on internal
documentation, such as invoices.
This complex type contains the
SupportingDocumentText and
SupportingDocumentNumberText. It will
allow users to create unique supporting
document text that can be viewed by both
trading parties in buy and sell transactions.

-------
Type of Change

Set minimum length for
element
Reordered elements
New Element Name

N/A
N/A
FuelTypeCode
N/A
N/A
N/A
Old Element Name

AssignmentCode
BuyReasonCode
SellReasonCode
SeparateReasonCode
RetireReasonCode
FuelCategoryCode
ComplianceLevel
Code
SeparateReasonCode
GenerateTransactionDetail
Type of
Transaction(
s) Affected

Buy
Sell
Separate
Retire
Buy
Sell
Separate
Retire
Generate
Retire
Sell
Generate
Required
Reporting
Element?

Yes
Yes
Yes
No
Yes
No
Description of Change
(cont.)
The new required minimum length for
reporting Assignment Code is 1 character
(and the maximum length is 2 characters).
The new required minimum length for
reporting any Reason Code (Buy, Sell,
Separate or Retire) is 1 character (and the
maximum length is 4 characters).
The new required minimum length for
reporting Fuel Type Code is 1 character (and
the maximum length is 3 characters).
The new required minimum length for
reporting Compliance Level Code is 1
character (and the maximum length is 2
characters).
Reordered elements for consistency across
all transaction complex types. Moved
SeparateReasonCode below RINYear.
Reordered elements for consistency across
all transaction complex types. See
EMTS_GenerateTransactionDetail_v2.0 for
element order.

-------