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.
------- |