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