Office of Enforcement and Compliance Assurance

Integrated Compliance Information System

ICIS Batch Compliance Schedule – Technical Specification

Version 1.2

Revised Final

June 18, 2012 Office of Enforcement and Compliance Assurance

Document Change History

Version Number Date Description 0.1 03/08/2011 Initial Draft Release. 1.0 04/28/2011 Changed “Phase III” to “Release 3” in the Introduction. Updated based on EPA Review Comments. Reordered Key Values. New Order is EnforcementActionIdentifier, FinalOrderIdentifier, PermitIdentifier, ComplianceScheduleNumber. 1.1 March 16, 2012 Clarified the text that explains default values in Section 2.1.3. Separated web-only fields from tags that are submitted in batch. Clarified that default values apply to New, Change, and Replace transactions. Clarified that if a field is blanked out on a Change or Replace like Change transaction, it will be defaulted in batch. Clarified in the Multi-Value Items section that duplicates (i.e., same data submitted multiple times) are ignored by the system for both individual data tags and multiple data tags. Exceptions to this rule appear as business rule rejections. Removed business rule CS060 from the technical specification as it will never be triggered. The rule states that Forum must be JDC (Judicial) or AFR (Administrative Formal). This rule is covered by CS030 and CS041. Modified the rule and error message for CS040. Changed the order of the tags to match the schema. Added the Schedule Event Code and Schedule Date for error messages CS100 to CS 140. Also added a note to specify that the message is issued once for each Schedule Event. Streamlined the Replace flow to be more consistent with the code and with other submission types. Updated the multi-value text in section 2.1.2. Instead of stating that all tags must be identical to be a duplicate, stated that only the tags that represent the key must be identical in order to be a duplicate. Added new business rule CS031 to check if the existing Enforcement Action is a Federal Activity. Updated the text for business rule CS140. Changed "schedule_event_code" to "Schedule Event Code". Updated the error message for CS090 to add the Schedule Date value. Updated Replace permissions to say that a user only needs sensitive data if the parent Enforcement Action record is sensitive instead of saying they always need it. Changed "A" to "The" in the beginning of error message CS050 to be consistent with other error messages. Added "the" before "Schedule Event" in error message CS090 to be consistent with other error messages. Added additional fields to the list of fields to not blank out during a Replace like Change transaction. For the list of fields that are not blanked out during

i ICIS Batch – Compliance Schedule, Version 1.2 Office of Enforcement and Compliance Assurance

Version Number Date Description a Replace transaction, changed “where the Compliance Schedule already exists” to “where the Compliance Schedule and Compliance Schedule Event already exist” for the Compliance Schedule Event section. Added Schedule Date Missed to the list of default values for a Compliance Schedule Event. 1.2 June 18, 2012 • Updated the data type in the data element mapping for the tag FinalOrderIdentifier from icis:NonNegativeIntegerMin1Max5Type to icis:IntegerRange1To99999Type.

ii ICIS Batch – Compliance Schedule, Version 1.2 Office of Enforcement and Compliance Assurance

Table of Contents

1. INTRODUCTION 5

1.1 PURPOSE 6 1.2 ASSUMPTIONS AND CONSTRAINTS 6 1.3 DOCUMENT OVERVIEW 7 2. VALIDATION AND PROCESSING 8

2.1 GENERAL BATCH PROCESSING RULES 8 2.1.1 Asterisks...... 8 2.1.2 Multi-Value Items...... 8 2.1.3 Default Values...... 11 2.2 MASS DELETE (X) COMPLIANCE SCHEDULES PROCESSING 11 2.2.1 Mass Delete Compliance Schedule Processing Flow...... 12 2.2.2 Mass Delete Compliance Schedule Sample Scenarios...... 16 2.3 REPLACE (R) COMPLIANCE SCHEDULE PROCESSING 17 2.3.1 Replace Compliance Schedule Processing Flow...... 18 2.3.2 Replace Compliance Schedule Sample Scenarios...... 25 2.4 BUSINESS RULES29 3. DATA ELEMENT MAPPING 32 4. XML SCHEMA 34 APPENDIX A: ACRONYMS 35

iii ICIS Batch – Compliance Schedule, Version 1.2 Office of Enforcement and Compliance Assurance

List of Tables

Table 2-1: Adding to a Multi-Value Item List...... 9 Table 2-2: Changing to a Multi-Value Item List...... 9 Table 2-3: Deleting from a Multi-Value Item List...... 10 Table 2-4: Mass Delete Compliance Schedule Processing...... 14 Table 2-5: Mass Delete Compliance Schedule Example 1...... 16 Table 2-6: Mass Delete Compliance Schedule Example 2...... 17 Table 2-7: Mass Delete Compliance Schedule Example 3...... 17 Table 2-8: Replace Compliance Schedule Processing...... 20 Table 2-9: Replace Compliance Schedule Example 1...... 25 Table 2-10: Replace Compliance Schedule Example 2...... 26 Table 2-11: Replace Compliance Schedule Example 3...... 27 Table 2-12: Replace Compliance Schedule Example 4...... 27 Table 2-13: Compliance Schedule Business Rules...... 29 Table 3-1: Batch Compliance Schedule Data Element Mapping...... 32 Table A-1: Acronym List...... 35

List of Figures

Figure 2-1: Mass Delete Compliance Schedule Processing Flow...... 13 Figure 2-2: Replace Compliance Schedule Processing Flow...... 19

iv ICIS Batch – Compliance Schedule, Version 1.2 Office of Enforcement and Compliance Assurance

1. INTRODUCTION

Many states already have their own tracking systems for National Pollutant Discharge Elimination System (NPDES) data. When those states are migrated to the Integrated Compliance Information System (ICIS), having them enter these data in ICIS through the Web interface would require them to perform duplicative data entry. Instead, users from these states may enter data in ICIS through batch submissions by which they extract data from their state system and submit it to ICIS in Extensible Markup Language (XML) files. The type of data a state submits through batch depends on the type of data tracked in their state system.

Current users of ICIS include Headquarters, Regions, direct-user states, hybrid states using Batch Discharge Monitoring Report (DMR) functionality, and full batch states. Batch modules are being added in groups, and the Compliance Schedule module is part of Full Batch Release 3.

The Compliance Schedule Technical Specification covers only State NPDES Compliance Schedule Activities. A Compliance Schedule is established as a component of a Final Order for Formal Enforcement Actions. It comprises a list of related activities or events that the Permittee or Facility must complete to be returned to compliance. Multiple Compliance Schedules may be associated with a single Final Order. The focus of this technical specification is the submission of Compliance Schedule data to ICIS through batch XML transactions. Data for other areas of the ICIS system (e.g., Formal Enforcement Actions, Effluent Trade Partners, and Single Event Violations) will be addressed in separate technical specifications.

The general process for states to submit batch data was defined for batch DMR processing and remains unchanged. States do not submit batch data directly to ICIS. Instead, batch files are submitted to the Environmental Protection Agency’s (EPA’s) Central Data Exchange (CDX) which then passes the files to ICIS. To submit data to CDX, the state must have a CDX User ID and password. This ID and password are specific to CDX and are completely unrelated to ICIS. An ICIS User ID must also be provided in the ID tag in the header of each XML file so that when ICIS receives the batch file(s), it can determine if the transactions in the file can be performed by the user submitting the batch. After receiving a batch from the state, CDX performs several important functions. They perform a virus scan to ensure that the state files are free of viruses and then assign a unique Transaction ID to the batch. This Transaction ID maps directly to the Batch ID that ICIS uses internally to manage processing. ICIS uses this Transaction ID to communicate information about the batch to CDX and the state. CDX then archives the batch and validates the XML files based on the rules in the XML schema. If problems are detected, CDX notifies the state so that the problems can be corrected. Upon completion of these tasks, CDX sends the error-free batches to ICIS.

For purposes of this document:

• “CDX User ID” refers to the ID the user must have to log in to CDX. • “ICIS User ID” refers to the state user’s ID in the ICIS system. • “Transaction ID” refers to the identifier CDX provides for each batch.

5 ICIS Batch – Compliance Schedule, Version 1.2 Office of Enforcement and Compliance Assurance

• “Batch ID” in all communications with users (e.g., audit reports, batch processing confirmation report) refers to the identifier CDX provides for each batch (i.e., the Transaction ID). • “Batch ID” in the ICIS Batch Operational Database (DB) refers to the batch identifier assigned by ICIS to make processing more efficient. • “Payload” in a batch refers to all of the XML transactions for a submission type.

A batch may contain many XML files, and within each XML file there can be up to one Payload for each Submission Type (Compliance Schedule). Each Payload may contain one or many XML transactions, each of which contains the Compliance Schedule data and a specific transaction type that identifies how ICIS should process the data. For Compliance Schedule, there are two valid XML transaction types: Mass Delete and Replace. The details of the Compliance Schedule transaction types are described in Section 2: Validation and Processing. After receiving a batch from CDX, ICIS parses it and saves each Compliance Schedule XML transaction to the database so that the individual Compliance Schedule XML transactions can be ordered and processed. After processing is complete for all files in a batch, ICIS sends a response notification to CDX, which then notifies the state, regional, or headquarters user when processing is complete.

1 Purpose

The purpose of this document is to provide a comprehensive overview of the submission of Compliance Schedule data through batch XML transactions using text descriptions, tables, and figures.

A major section of this Compliance Schedule Technical Specification, Section 2: Validation and Processing, details the two valid XML transaction types for Compliance Schedules (Mass Delete and Replace). Provided with these transactions are the business rules that govern batch Compliance Schedule transactions, as well as the accompanying error/warning messages, serving to notify users of the data in error and provide them with the information necessary to correct the problems.

2 Assumptions and Constraints

The following assumptions and constraints apply to the ICIS Batch Compliance Schedule Technical Specification:

• ICIS will process batches within a state in the order they are received from CDX. CDX will not apply a timestamp to each batch that is submitted by the state. In addition, CDX cannot guarantee that batches will be sent to ICIS in the same order that CDX received them from the state. As a result, ICIS cannot guarantee that batches will be processed in the order in which the state submitted them.

• Users will submit batch files to CDX in the correct chronological order. A procedure will be put in place by each state to ensure that a state sends only one batch at a time, and does not send a new batch until they have received confirmation that the previous batch has been processed.

• CDX will perform a schema validation on every batch. ICIS will not perform another schema validation. If schema errors exist that are not caught by the CDX validation, unexpected results will occur.

• The business rules for Compliance Schedules entered via batch should be the same as State Compliance Schedules entered via the web application. Any differences will be noted in the “Where Enforced (Web)” Column of the Business Rules table in Section 2: Validation and Processing.

• Design decisions will be made to minimize software changes that will be needed to incorporate the batch entry of other data families. EPA will be consulted, as appropriate, as these decisions are made.

• ICIS will not save a transaction if there are any errors within the transaction, though transactions will be saved if only warnings/informational messages exist. The rules for accepting and rejecting transactions are described in detail in Section 2: Validation and Processing.

3 Document Overview

The following sections comprise the remainder of this technical specification:

• Section 2: Validation and Processing – This section describes the processing of Mass Delete and Replace Compliance Schedule XML transactions, and the business rules that apply to each transaction type.

• Section 3: Data Element Mapping – This section provides a mapping between the Permit Compliance System (PCS) Acronym, XML Tag Name, ICIS Screen Name, and ICIS Database Name for Compliance Schedule data elements.

• Section 4: XML Schema – This section provides a list of the XML schemas related to Compliance Schedules.

• Appendix A: Acronyms – This section provides a list of all acronyms used in the document.

2. VALIDATION AND PROCESSING

After receiving a batch from CDX, ICIS parses the batch Compliance Schedule XML transactions, saves each to the database, and groups them by transaction type. The valid transaction types for Compliance Schedules are Mass Delete and Replace. ICIS must process these groups in the proper order to achieve the desired results. The ICIS Batch Design Document Appendix D: ICIS Batch Submission Types and Processing Order detail the processing order for all ICIS batch submissions. This section describes specific fields that require special processing as well as the detailed processing of the two Compliance Schedule transaction types.

Key values are used throughout ICIS Batch to identify data in the ICIS database. The ICIS Batch Schema requires that key values be entered for all transactions. The key values for Compliance Schedule transactions are:

• Enforcement Action Identifier • Final Order Identifier • Permit Identifier • Compliance Schedule Number

The following sub-sections describe general processing rules related to asterisks and the detailed processing of Compliance Schedule XML transactions.

4 General Batch Processing Rules

It is important to understand the following general batch processing rules for ICIS:

Asterisks

Users must have the ability to remove data from fields through batch transactions. This is accomplished through the use of asterisks (*). The asterisk is not stored in ICIS, but instead is used to signal the system that the field should be blanked out. Asterisks can also be submitted in Replace transactions. When that happens, they are interpreted by the system as blanks. It is not necessary for the user to submit asterisks in Replace transactions because leaving the tag out of the XML transaction achieves the same result (i.e., the field is left blank), but ICIS has been designed to process asterisks in those cases.

Multi-Value Items

Data fields or sections for which multiple values can be entered are referred to in this technical specification as multi-value items. Whenever tags for one of these multi-value items are included in a payload, ICIS will replace all existing values for that item with the values submitted in the tag(s), regardless of the transaction type submitted. The Compliance Schedule schema contains multi-value fields which contain multiple data tags.

Multiple Data Tags – Some multi-value items contain multiple data tags which can be repeated, as a group, multiple times within a transaction. Below is an example for a Compliance Schedule:

CS016 2010-02-01 2010-02-15 2010-02-15 2010-12-15 Special use Special use CS001 2010-03-01 2010-03-01 2010-03-01 2010-03-01 Special use Special use 25000

Note: In the above XML example, the ComplianceSchedulePenaltyAmount tag can only be submitted for the following Schedule Event Codes: CS001, CS002, CS003, or CS033.

If data already exist for one of these multi-value items for the Compliance Schedule in ICIS and the user wishes to add new values while keeping the existing values, they would include all of the values that they wish to have for the field (i.e., all existing values, plus the new values) in their XML submission. The table below provides an example.

Table 2-1: Adding to a Multi-Value Item List

ScheduleEventCode in ICIS DB ScheduleEventCode in XML Result in ICIS DB After Processing Submission CS001 CS001 CS001 PR008 PR008 PR008 CS032 CS032

If data already exist for one of these multi-value items for the Compliance Schedule in ICIS and the user wishes to change one of the values, they would include all of the values that they wish to have for the field (i.e., existing values they wish to keep, plus new values) in their XML submission. The table below provides an example.

Table 2-2: Changing to a Multi-Value Item List

ScheduleEventCode in ICIS DB ScheduleEventCode in XML Result in ICIS DB After Processing Submission CS001 CS001 CS001 PR008

ScheduleEventCode in ICIS DB ScheduleEventCode in XML Result in ICIS DB After Processing Submission CS032 CS032

If data already exist for one of these multi-value items for the Compliance Schedule in ICIS and the user wishes to remove all but one of the values, they would include only the value that they wish to have for the field (i.e., existing values they wish to keep) in their XML submission. The table below provides an example.

Table 2-3: Deleting from a Multi-Value Item List

ScheduleEventCode in ICIS DB ScheduleEventCode in XML Result in ICIS DB After Processing Submission CS001 CS001 CS001 PR008 CS032

Users must also have the ability to blank out all values for these multi-value items. This is accomplished by submitting one row of the multi-value item with an asterisk as the value. The rules for doing this are described below:

• Individual Data Tag – If an asterisk is submitted in an individual data tag, ICIS will blank out all existing values for the corresponding field.

• Multiple Data Tags:

 If asterisks are submitted in all required tags and the optional tags are not included, ICIS will blank out all existing values for the corresponding multi-value item.

 If asterisks are submitted in all required tags and values are submitted in one or more optional tags, ICIS will blank out all existing values for the corresponding multi- value item (ignoring the data in the optional tags).

 If asterisks are submitted in some required tags and values are submitted in other required tags, ICIS will reject the transaction. This is addressed through business rules, with error messages, detailed in the business rules table.

 If there are no required tags for a multi-value item and asterisks are entered in one or more of the optional tags:

• If only asterisks are submitted, ICIS will blank out all existing values for the corresponding multi-value item.

• If a combination of asterisks and values are submitted, ICIS will reject the transaction. This is addressed through business rules, with error messages, detailed in the business rules table. As noted above, asterisks should only be used as an indication to blank out all values for a field, and that should be the only row of data that is submitted for that field. However, it is possible

that a transaction will contain multiple rows of a multi-value item, some with asterisks and some without. In that situation, ICIS will evaluate each row for validity. If any rows are invalid, ICIS will reject the transaction. If all rows are valid, ICIS will save only the values submitted, ignoring the “blanked out” rows.

If duplicate multi-value items are submitted (i.e., the same data submitted multiple times for different multi-value items), then ICIS will save one of the duplicate multi-value items and ignore the other duplicates. A multi-value item is considered a duplicate if the key value tags are identical (i.e., fields in ICIS that must be unique for each multi-value). If there are duplicate multi-value items, ICIS cannot guarantee which multi-value item will be saved. This logic applies to both individual data tag and multiple data tag multi-value items. Any exceptions to this processing logic will appear as a business rule and will result in a rejected transaction.

The Compliance Schedule Submission type contains only one multi-value item: Compliance Schedule Event. For this multi-value, if the Schedule Event already exists in ICIS and is submitted in the XML transaction, the record will be edited instead of deleted and added. For more details, see Section 6Replace (R) Compliance Schedule Processing.

Default Values

Default values can include both web-only fields and web/batch fields. They apply to New, Change, and Replace batch transactions. Default values are always set for New and Replace like New transactions, and are set for Change and Replace like Change transactions for tags that are blanked out.

The following is a list of web-only default values for Compliance Schedule transactions:

• Compliance Schedule Type set to:

 ‘A’ when the Final Order to which the schedule will be linked is the result of an Administrative Formal Enforcement Action.

 ‘J’ when the Final Order to which the schedule will be linked is the result of a Judicial Enforcement Action.

• Schedule Date Missed set to: No (schedule_date_missed_flag: N).

5 Mass Delete (X) Compliance Schedules Processing

The Mass Delete Compliance Schedule XML transaction allows the user to remove an existing Compliance Schedule in ICIS. When a Compliance Schedule is removed from ICIS, the Compliance Schedule is removed from the Final Order and any Schedule Violations for the Compliance Schedule will be deleted. Also included in this section are sample Mass Delete Compliance Schedule scenarios.

Mass Delete Compliance Schedule Processing Flow

Figure 2-1: Mass Delete Compliance Schedule Processing Flow is a diagram depicting the processing of a Mass Delete Compliance Schedule transaction. A table detailing each step in the flow diagram is also included in this section.

Figure 2-1: Mass Delete Compliance Schedule Processing Flow

Table 2-4: Mass Delete Compliance Schedule Processing contains a description of the items from the Mass Delete Compliance Schedule Processing flow. The Item Number column refers to the Processing step being referenced. The Item Description column gives a more in-depth explanation of each step of the process. The Mapping to Business Rules Table column references the specific business rules that are checked in that step. All other business rules relating to Compliance Schedule can be found in Table 2-13: Compliance Schedule Business Rules. Table 2-4: Mass Delete Compliance Schedule Processing

Item Item Description Mapping To Business Rule Table Number 1 Does the Compliance Schedule exist in ICIS for the key data entered? CS030 ICIS determines if a Compliance Schedule exists in ICIS that matches the key data submitted. The XML key tags for matching a Compliance Schedule is EnforcementActionIdentifier, FinalOrderIdentifier, PermitIdentifier, and ComplianceScheduleNumber. If a matching Compliance Schedule is found in ICIS, processing continues at #2, otherwise processing continues at #1A. 1A Reject transaction. Write 1 error message to the error log. CS030 If the XML key tags for the Compliance Schedule cannot be found in ICIS, then ICIS rejects the Mass Delete Compliance Schedule request. ICIS writes an error message to the error log, and processing of this Mass Delete Compliance Schedule XML transaction ends. 2 Is existing Enforcement Action Federal? CS031 ICIS determines if the existing Enforcement Action of the Compliance Schedule is a Federal Activity. If this is true, processing continues at #2A; otherwise processing continues at #3. 2A Reject transaction. Write 1 error message to the error log. CS031 ICIS has determined that the existing Enforcement Action is a Federal Activity, rejects the transaction, writes an error message to the error log, and end processing of this transaction. 3 Does user have privileges to perform Mass Delete Compliance Schedule XML transaction? BAT020 ICIS determines if the user has privileges to perform a Mass Delete Compliance Schedule transaction and if the user has the authority to conduct a Mass Delete Compliance Schedule transaction for the state requested. ICIS applies the same security rules for batch as it does for the web, and uses the same set of permissions. The user must have the Delete Formal Enforcement Action function, which is available as part of the Formal Enforcement Action Deletion role. In addition, the user must have Sensitive Data Access privileges to perform this transaction if the Compliance Schedule’s belongs to a sensitive Formal Enforcement Action. An Administrative Formal Enforcement Action is sensitive unless a Milestone Complaint/Proposed Order Actual Date exists or a Final Order exists with a Final Order Issue Date. A Judicial Enforcement Action is sensitive unless the Milestone Complaint Filed with Court Actual Date exists. Note: if the Compliance Schedule exists for an Administrative Formal Enforcement Action, then the Enforcement Action will always be non-sensitive. If the ICIS User ID has the correct privileges, processing continues at #4, otherwise processing continues at #3A.

Item Item Description Mapping To Business Rule Table Number 3A Reject transaction. Write 1 error message to the error log. BAT020 If the ICIS User ID does not have the correct privileges defined in ICIS for this Mass Delete Compliance Schedule transaction, then ICIS rejects the entire Mass Delete Compliance Schedule XML transaction. ICIS writes an error message to the error log, and processing of this Mass Delete Compliance Schedule XML transaction ends. 4 Is this the only Compliance Schedule for the Final Order? N/A ICIS determines if the Compliance Schedule is the only Compliance Schedule for the particular Final Order. If the Compliance Schedule is the only Compliance Schedule for the Final Order, processing continues at #4A; otherwise processing continues at #5. 4A Are any Violations linked to the Final Order? N/A ICIS determines if there are any Violations linked to the particular Final Order for the Compliance Schedule’s NPDES ID. If there are Violations linked to the Final Order for the Compliance Schedule’s NPDES ID, processing continues at #3B; otherwise processing continues at #4. 4B Call EA RNC BGP for Identified Violations. N/A ICIS calls Enforcement Action (EA) Reportable Non-compliance (RNC) Background Process (BGP) to determine if violations need to be updated. For further information on the background processing rules refer to the ICIS–NPDES Technical Specification document for Schedule Violations. Processing continues at #4C. 4C Did Background Processing Complete Successfully? CS150 ICIS determines whether Enforcement Action RNC Background Processing completed successfully or if errors were encountered. If the EA RNC background processing completed successfully, processing continues at #5; otherwise processing continues at #4D. 4D Reject transaction. Write 1 error message to the error log. CS150 If EA RNC Background Processing did not complete successfully, or if errors were encountered, the Mass Delete Compliance Schedule XML transaction is rejected. ICIS writes an error message to the error log for each business rule violation, and processing of this Mass Delete Compliance Schedule XML transaction ends. 5 Delete the Compliance Schedule and its child records. N/A ICIS has determined that this Compliance Schedule is valid for deletion. The Compliance Schedule, Schedule Violations, and any links between Violations and Enforcement Actions and/or Final Orders are deleted. Processing Continues at #6. 6 Accept transaction. N/A ICIS logs a successful Mass Delete Compliance Schedule transaction. Processing of the Mass Delete Compliance Schedule XML transaction is complete.

Mass Delete Compliance Schedule Sample Scenarios

A Mass Delete Compliance Schedule transaction should contain only the key data, though if it contains any other data, ICIS will still process the Mass Delete. Examples of possible Mass Delete Compliance Schedule scenarios are described below.

Example 1

If the submitted Mass Delete Compliance Schedule XML includes:

• Valid combination of Enforcement Action Identifier, Final Order Identifier, NPDES ID, and Compliance Schedule Number.

• Compliance Schedule Event data exists.

• Schedule Event Violation data exists.

ICIS will accept the transaction and remove the Compliance Schedule and all of its child data (i.e., Compliance Schedule Events and Schedule Event Violations) from the database. Table 2-5: Mass Delete Compliance Schedule Example 1 provides an example.

Table 2-5: Mass Delete Compliance Schedule Example 1

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA-123456789; Final Order Identifier: 1; NPDES ID: VA1234567; Compliance Schedule Number: 1 Compliance Schedule Event Data Mass Delete for Compliance Schedule Compliance Schedule Event Violation data

Example 2

• Invalid combination of Enforcement Action Identifier, Final Order Identifier, NPDES ID, and Compliance Schedule Number.

• NPDES ID does not exist.

ICIS will reject the transaction because the combination of Enforcement Action Identifier, Final Order Identifier, and NPDES ID does not exist. Table 2-6: Mass Delete Compliance Schedule Example 2 provides an example.

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA- Mass Delete for Compliance Schedule Enforcement Action Identifier: VA- 123456789; Final Order Identifier: 4; – Enforcement Action Identifier: VA- 123456789; Final Order Identifier: 4; NPDES ID: VA1234567; Compliance 222222222; Final Order Identifier: 4; NPDES ID: VA1234567; Compliance Schedule Number: 1 NPDES ID: VA2222222; Compliance Schedule Number: 1 Schedule Number: 1 Compliance Schedule Event Data Compliance Schedule Event Data Compliance Schedule Event Compliance Schedule Event Violation Violation data data

Example 3

• Invalid combination of Enforcement Action Identifier, and Final Order Identifier, NPDES ID, and Compliance Schedule Number.

• Compliance Schedule Number does not exist.

ICIS will reject the transaction because the Compliance Schedule does not exist. Table 2-7: Mass Delete Compliance Schedule Example 3 provides an example.

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA- Mass Delete for Compliance Schedule Enforcement Action Identifier: VA- 123456789; Final Order Identifier: 4; – Enforcement Action Identifier: VA- 123456789; Final Order Identifier: 4; NPDES ID: VA1234567; Compliance 123456789; Final Order Identifier: 4; NPDES ID: VA1234567; Compliance Schedule Number: 1 NPDES ID: VA1234567; Compliance Schedule Number: 1 Schedule Number: 2 Compliance Schedule Event Data Compliance Schedule Event Data Compliance Schedule Event Compliance Schedule Event Violation Violation data data

6 Replace (R) Compliance Schedule Processing

The Replace Compliance Schedule transaction allows the user to submit Compliance Schedule data to ICIS without considering the current state of the Compliance Schedule data in ICIS. In processing the transaction, ICIS will determine whether or not the Compliance Schedule already exists. If the Compliance Schedule does not exist in ICIS, the Replace transaction will add a new Compliance Schedule to the Final Order of the Enforcement Action as well as all of the Compliance Schedule Events provided in the XML to the Compliance Schedule. If the Compliance Schedule already exists in ICIS, the Replace transaction will update the existing record in ICIS with the data provided, blanking out fields that were not submitted. If the existing Compliance Schedule already exists in ICIS, existing Compliance Schedule Events that are

included in the XML are updated, existing Compliance Schedule Events that are not included in the XML are deleted, and new Compliance Schedule Events are added. For unchanged Compliance Schedule Events, any previously existing historical data (i.e., Schedule Violations) will remain. Any new or updated Compliance Schedule Events will be submitted to background processing for compliance determination based on the submitted data. Also included in this section are sample Replace Compliance Schedule scenarios.

Replace Compliance Schedule Processing Flow

Figure 2-2: Replace Compliance Schedule Processing Flow is a diagram depicting the processing of a Replace Compliance Schedule transaction. A table detailing each step in the flow diagram is also included in this section.

In a Replace transaction, ICIS will replace the data for the Compliance Schedule with the data submitted in the XML. It is important to note the Compliance Schedule Type field cannot be submitted through batch transactions, because it is system-generated.

In a Replace transaction where the Compliance Schedule already exists in ICIS, the system will not blank out the following Compliance Schedule fields:

• Order Paragraph Number • Related Component • Forum (comp_schedule_type_flag)

In a Replace transaction where the Compliance Schedule and Compliance Schedule Event already exist in ICIS, the system will also not blank out the following Compliance Schedule Event fields:

• schedule_date_missed_flag.

The processing of a Replace Compliance Schedule transaction in ICIS is described below.

Figure 2-2: Replace Compliance Schedule Processing Flow

Table 2-8: Replace Compliance Schedule Processing contains a description of the items from the Replace Compliance Schedule flow. The Item Number column refers to the Processing step being referenced. The Item Description column gives a more in-depth explanation of each step of the process. The Mapping to Business Rules Table column references the specific business rules that are checked in that step. All other business rules relating to Compliance Schedules can be found in Table 2-13: Compliance Schedule Business Rules. Table 2-8: Replace Compliance Schedule Processing

Item Item Description Mapping To Business Rule Table Number 1 Does user have privileges to perform Replace Compliance Schedule XML transaction? BAT020 ICIS determines if the user has privileges to perform a Replace Compliance Schedule transaction and if the user has the authority to conduct a Replace Compliance Schedule transaction for the state requested. ICIS applies the same security rules for batch as it does for the web, and uses the same set of permissions. The user must have the Add and Edit Formal Enforcement Action function, which is available as part of the Formal Enforcement Action Editor role. In addition, the user must have Sensitive Data Access privileges to perform this transaction if the Compliance Schedule’s belongs to a sensitive Formal Enforcement Action. An Administrative Formal Enforcement Action is sensitive unless a Milestone Complaint/Proposed Order Actual Date exists or a Final Order exists with a Final Order Issue Date. A Judicial Enforcement Action is sensitive unless the Milestone Complaint Filed with Court Actual Date exists. Note: if the Compliance Schedule exists for an Administrative Formal Enforcement Action, then the Enforcement Action will always be non-sensitive. If the ICIS User ID has the correct privileges, processing continues at #2, otherwise processing continues at #1A. 1A Reject transaction. Write 1 error message to the error log. BAT020 If the ICIS User ID does not have the correct privileges defined in ICIS for this Replace Compliance Schedule transaction, then ICIS rejects the entire Replace Compliance Schedule XML transaction. ICIS writes an error message to the error log, and processing of this Replace Compliance Schedule XML transaction ends. 2 Does a Compliance Schedule exist in ICIS for the key data entered? N/A ICIS determines if a Compliance Schedule already exists in ICIS that matches the key data submitted. The XML key tag for matching a Compliance Schedule is EnforcementActionIdentifier, FinalOrderIdentifier, PermitIdentifier, and ComplianceScheduleNumber. If a matching Compliance Schedule is found in ICIS, processing continues at #3, otherwise processing continues at #2A. 2A Does the NPDES ID exist in ICIS? CS040 ICIS determines if the NPDES ID provided matches an existing NPDES ID in ICIS. If the NPDES ID exists, processing continues at #2B; otherwise processing continues at #2A1.

Item Item Description Mapping To Business Rule Table Number 2A1 Reject transaction. Write 1 error message to the error log. CS040 If the NPDES ID provided for the Compliance Schedule cannot be found in ICIS, then ICIS rejects the Replace Compliance Schedule request. ICIS writes an error message to the error log and processing of this Replace Compliance Schedule XML transaction ends. 2B Do EA and Final Order exist? CS041 ICIS determines if the Enforcement Action and Final Order provided matches an existing Enforcement Action and Final Order in ICIS. If the Enforcement Action and Final Order exist, processing continues at #2C; otherwise processing continues at #2B1. 2B1 Reject Transaction. Write 1 error msg per business rule violation to the error log. CS041 If the Enforcement Action and Final Order provided for the Compliance Schedule cannot be found in ICIS, then ICIS rejects the Replace Compliance Schedule request. ICIS writes an error message to the error log and processing of this Replace Compliance Schedule XML transaction ends. 2C Is existing Enforcement Action Federal? CS031 ICIS determines if the existing Enforcement Action of the Compliance Schedule is a Federal Activity. If this is true, processing continues at #2C1; otherwise processing continues at #2D. 2C1 Reject transaction. Write 1 error message to the error log. CS031 ICIS has determined that the existing Enforcement Action is a Federal Activity, rejects the transaction, writes an error message to the error log, and end processing of this transaction. 2D Are there duplicate Schedule Events? CS080 ICIS determines if there are duplicate Schedule Events in the XML transaction. If this is true, processing continues at #2D1; otherwise processing continues at #2E. 2D1 Reject transaction. Write 1 error message to the error log. CS080 ICIS has determined that there are duplicate Schedule Events, rejects the transaction, writes an error message to the error log, and end processing of this transaction. 2E Are data valid for Replace (like New) transactions? CS (050, 070, 090, 100, 110, 120, 130, ICIS determines if all required data are submitted and checks validity of all required and optional data. If 140) required data are submitted and required and optional data are valid according to the business rules, processing continues at #7; otherwise processing continues at #2E1. 2E1 Reject Transaction. Write 1 error msg per business rule violation to the error log. Same as #2E If ICIS determines that required and/or optional data are incomplete and/or invalid, ICIS rejects the entire Replace Compliance Schedule transaction. ICIS writes an error message to the error log for each business rule violation and processing of this Replace Compliance Schedule XML transaction ends. 3 Is existing Enforcement Action Federal? CS031 ICIS determines if the existing Enforcement Action of the Compliance Schedule is a Federal Activity. If this is true, processing continues at #3A; otherwise processing continues at #7.

Item Item Description Mapping To Business Rule Table Number 3A Reject transaction. Write 1 error message to the error log. CS031 ICIS has determined that the existing Enforcement Action is a Federal Activity, rejects the transaction, writes an error message to the error log, and end processing of this transaction. 4 Are there duplicate Schedule Events? CS080 ICIS determines if there are duplicate Schedule Events in the XML transaction. If this is true, processing continues at #4A; otherwise processing continues at #5. 4A Reject transaction. Write 1 error message to the error log. CS080 ICIS has determined that there are duplicate Schedule Events, rejects the transaction, writes an error message to the error log, and end processing of this transaction. 5 Overlay Compliance Schedule Event data in ICIS with the Compliance Schedule Event data N/A submitted in the XML. For Replace transactions where the Compliance Schedule already exists in ICIS, the transaction will update the existing Compliance Schedule record in ICIS with the data provided, blanking out fields that were not submitted. Existing Compliance Schedule Events that are included in the XML are updated, existing Compliance Schedule Events that are not included in the XML are deleted, and new Compliance Schedule Events are added. Existing Compliance Schedule Events that match the XML transaction are updated instead of deleted and re-added in order to preserve historical data such as Violations and links. Processing continues at #6. 6 Are data valid for Replace (like Change) transactions? CS (050, 070, 090, 100, 110, 120, 130, ICIS determines if all required data are submitted and checks validity of all required and optional data. If 140) required data are submitted and required and optional data are valid according to the business rules, processing continues at #7; otherwise processing continues at #6A. 6A Reject Transaction. Write 1 error msg per business rule violation to the error log. Same as #6 If ICIS determines that required and/or optional data are incomplete and/or invalid, ICIS rejects the entire Replace Compliance Schedule transaction. ICIS writes an error message to the error log for each business rule violation and processing of this Replace Compliance Schedule XML transaction ends. 7 Were any Schedule Events added to the parent Compliance Schedule? N/A ICIS determines if any Compliance Schedule Events were added to the parent Compliance Schedule as a result of this transaction. If this is true, processing continues at #7A; otherwise processing continues at #8. 7A Is Schedule Date + 31 ≤ Current Date for any of the added Events? N/A For each of the Compliance Schedule Events identified in #7, ICIS determines if the Schedule Date + 31 ≤ Current Date. If this is true for any of the identified Schedule Events, processing continues at #7B; otherwise processing continues at #8.

Item Item Description Mapping To Business Rule Table Number 7B Call Schedule Violation Background Processing. N/A ICIS calls the Schedule Violation Background Process for the Schedule Events identified in #7A to determine if violations need to be added, updated, or deleted. For further information on the background processing rules refer to the ICIS–NPDES Technical Specification document for Schedule Violations. Processing continues at #7C. 7C Did Background Processing Complete Successfully? CS150 ICIS determines whether Schedule Violation Background Processing completed successfully or if errors were encountered. If the EA RNC background processing completed successfully, processing continues at #8; otherwise processing continues at #7D. 7D Reject transaction. Write 1 error message to the error log. CS150 If Schedule Violation Background Processing did not complete successfully, or if errors were encountered, the Replace Compliance Schedule XML transaction is rejected. ICIS writes an error message to the error log for each business rule violation, and processing of this Replace Compliance Schedule XML transaction ends. 8 Were any Schedule Events edited? N/A ICIS determines if any Compliance Schedule Events were edited as a result of this transaction. If this is true, processing continues at #8A; otherwise processing continues at #9. 8A Did Actual Date or Report Received Date Change for any of the edited Events? N/A For each of the Compliance Schedule Events identified in #8, ICIS determines if the Actual Date or Report Received Date Changed for any of the edited Schedule Events. If this is true for any of the identified Schedule Events, processing continues at #8B; otherwise processing continues at #9. 8B Call Schedule Violation Background Processing. N/A ICIS calls the Schedule Violation Background Process for the Schedule Events identified in #8A to determine if violations need to be added, updated, or deleted. For further information on the background processing rules refer to the ICIS–NPDES Technical Specification document for Schedule Violations. Processing continues at #8C. 8C Did Background Processing Complete Successfully? CS150 ICIS determines whether Schedule Violation Background Processing completed successfully or if errors were encountered. If the EA RNC background processing completed successfully, processing continues at #8; otherwise processing continues at #8D. 8D Reject transaction. Write 1 error message to the error log. CS150 If Schedule Violation Background Processing did not complete successfully, or if errors were encountered, the Replace Compliance Schedule XML transaction is rejected. ICIS writes an error message to the error log for each business rule violation, and processing of this Replace Compliance Schedule XML transaction ends.

Item Item Description Mapping To Business Rule Table Number 9 Is this the only Compliance Schedule for the Final Order? N/A ICIS determines if the Compliance Schedule is the only or first Compliance Schedule for the particular Final Order. If the Compliance Schedule is the only or first Compliance Schedule for the Final Order, processing continues at #9A; otherwise processing continues at #10. 9A Are any Violations linked to the Final Order? N/A ICIS determines if there are any Violations linked to the particular Final Order for the Compliance Schedule’s NPDES ID. If there are Violations linked to the Final Order for the Compliance Schedule’s NPDES ID, processing continues at #9B; otherwise processing continues at #10. 9B Call EA RNC BGP for Identified Violations. N/A ICIS calls Enforcement Action (EA) RNC Background Process to determine if violations need to be added, updated, or deleted. For further information on the background processing rules refer to the ICIS–NPDES Technical Specification document for Schedule Violations. Processing continues at #9C. 9C Did Background Processing Complete Successfully? CS150 ICIS determines whether Enforcement Action RNC Background Processing completed successfully or if errors were encountered. If the EA RNC background processing completed successfully, processing continues at #10; otherwise processing continues at #9D. 9D Reject transaction. Write 1 error message to the error log. CS150 If EA RNC Background Processing did not complete successfully, or if errors were encountered, the Replace Compliance Schedule XML transaction is rejected. ICIS writes an error message to the error log for each business rule violation, and processing of this Replace Compliance Schedule XML transaction ends.

10 Save the Compliance Schedule and its child records to the database. N/A ICIS has determined that the Replace Compliance Schedule transaction is valid. The Compliance Schedule and any Compliance Schedule Events and Violations are saved to the ICIS database and processing continues at #11. 11 Accept transaction. N/A ICIS logs a successful Replace Compliance Schedule transaction. Processing of the Replace Compliance Schedule XML transaction is complete.

Replace Compliance Schedule Sample Scenarios

Examples of possible Replace Compliance Schedule scenarios are described below.

Example 1

If the submitted Replace Compliance Schedule XML includes:

• Valid combination of Enforcement Action Identifier, Final Order Identifier, NPDES ID, and Compliance Schedule Number.

• Compliance Schedule data does not exist.

ICIS will accept the transaction and add the Compliance Schedule and all of its child data (i.e., Compliance Schedule Events) to the database and generate any Schedule Event Violations based on the submitted data. Table 2-9: Replace Compliance Schedule Example 1 provides an example.

Table 2-9: Replace Compliance Schedule Example 1

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- 123456789 123456789 Final Order Identifier: 1 Final Order Identifier: 1 NPDES ID: VA1234567 NPDES ID: VA1234567 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Compliance Schedule Comments: Compliance Schedule Comments: Permittee missed their last compliance Permittee missed their last schedule interim date compliance schedule interim date Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Event Code: CS016 Schedule Event Code: CS016 Schedule Date: 05/01/2010 Schedule Date: 05/01/2010 Report Received Date: 06/15/2010 Report Received Date: 06/15/2010 Actual Date: 06/01/2010 Actual Date: 06/01/2010 Projected Date: 06/01/2010 Projected Date: 06/01/2010 Compliance Schedule Event Violation data

Example 2

• Valid combination of Enforcement Action Identifier, Final Order Identifier, NPDES ID, and Compliance Schedule data exists.

• Valid data for a Compliance Schedule Event.

ICIS will accept the transaction and update the existing Compliance Schedule and all of its child data (i.e., Compliance Schedule Events) to the database. Table 2-10: Replace Compliance Schedule Example 2 provides an example.

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- 123456789 123456789 123456789 Final Order Identifier: 1 Final Order Identifier: 1 Final Order Identifier: 1 NPDES ID: VA1234567 NPDES ID: VA1234567 NPDES ID: VA1234567 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Event Code: CS001 Schedule Event Code: CS001 Schedule Event Code: CS001 Schedule Date: 05/01/2010 Schedule Date: 05/01/2010 Schedule Date: 05/01/2010 Report Received Date: 06/15/2010 Report Received Date: 06/15/2010 Actual Date: 06/01/2010 Actual Date: 06/01/2010 Projected Date: 06/01/2010 Projected Date: 06/01/2010 Schedule User Defined Data Element 1: Schedule User Defined Data Element Special Use 1: Special Use Schedule User Defined Data Element 2: Schedule User Defined Data Element Special Use 2: Special Use Schedule Event Comments: Required Schedule Event Comments: Required for this permit only for this permit only Compliance Schedule Penalty Amount: Compliance Schedule Penalty 25000 Amount: 25000

Note: In the above, Table 2-11, the Compliance Schedule Penalty Amount can only be submitted for the following Schedule Event Codes: CS001, CS002, CS003, or CS033.

Example 3

• Valid combination of Enforcement Action Identifier, Final Order Identifier, and NPDES ID,

• Compliance Schedule data exists.

• Data that violate a business rule (e.g., Report Received Date must be greater than or equal to the Actual Date).

ICIS will reject the transaction because the Report Received Date must be greater than or equal to the Actual Date. Table 2-11: Replace Compliance Schedule Example 3 provides an example.

Compliance Schedule in ICIS Compliance Schedule XML Result in ICIS DB After DB Submission Processing Enforcement Action Identifier: Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- VA-123456789 123456789 123456789 Final Order Identifier: 1 Final Order Identifier: 1 Final Order Identifier: 1 NPDES ID: VA1234567 NPDES ID: VA1234567 NPDES ID: VA1234567 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Event Code: CS016 Schedule Event Code: CS016 Schedule Event Code: CS016 Schedule Date: 05/01/2010 Schedule Date: 05/01/2010 Schedule Date: 05/01/2010 Report Received Date: 05/11/2010 Actual Date: 06/01/2010 Projected Date: 06/01/2010

Example 4

• Valid combination of Enforcement Action Identifier, Final Order Identifier, and NPDES ID.

• Compliance Schedule data exists.

• Compliance Schedule Events data exists and it’s the only Compliance Schedule Event for the Compliance Schedule.

• Data that violate a business rule (e.g., A Compliance Schedule must include one or more Compliance Schedule Events).

ICIS will reject the transaction because a Compliance Schedule must include one or more Compliance Schedule Events. Table 2-12: Replace Compliance Schedule Example 4 provides an example.

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- Enforcement Action Identifier: VA- 123456789 123456789 123456789 Final Order Identifier: 1 Final Order Identifier: 1 Final Order Identifier: 1 NPDES ID: VA1234567 NPDES ID: VA1234567 NPDES ID: VA1234567 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Compliance Schedule Number: 1 Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Descriptor Code: CMO Schedule Event Code: CS016 Schedule Event Code: CS016 Schedule Event Code: CS016 Schedule Date: 05/01/2010 Schedule Date: * Schedule Date: 05/01/2010

Compliance Schedule in ICIS DB Compliance Schedule XML Result in ICIS DB After Processing Submission Report Received Date: 06/15/2010 Report Received Date: * Report Received Date: 06/15/2010 Actual Date: 06/01/2010 Actual Date: * Actual Date: 06/01/2010 Projected Date: 06/01/2010 Projected Date: * Projected Date: 06/01/2010

7 Business Rules

Table 2-13: Compliance Schedule Business Rules lists the business rules that apply to Compliance Schedule transactions. Each row has a unique Error Code which identifies the business rule. The Business Rules column describes the specific business rule that is being applied to the Compliance Schedule transactions. The naming of the data fields is consistent with the existing production system terminology and not the batch XML schema terminology. The Where Enforced (Web) column identifies the code tier that is responsible for enforcing the business rule from the Web Application. Business Rules that have a Where Enforced column of Business rule layer can often be reused for ICIS Batch. The Error/Warning Message lists the specific message (including data) that will be displayed on the audit report along with code. The error/warning messages use the XML schema terminology for data so that users can easily identify the specific data tags that are in error. On the audit reports, the key values for each transaction will be concatenated. The key value that will be displayed for Compliance Schedule transactions are: Enforcement Action Identifier, Final Order Identifier, Permit Identifier, and Compliance Schedule Number. The Applicable Transaction Types column identifies all transaction types to which the business rule applies.

Table 2-13: Compliance Schedule Business Rules

Error/ Business Rules Where Error/Warning Message Applicable Warning Enforced Transaction Code (Web) Types BAT010 Transaction Type must be valid for Compliance Schedule. Valid N/A Transaction Type is not valid X, R Transaction Type are X (Mass Delete) and R (Replace). for . BAT020 User must have privileges to perform the transaction. This relates GUI (Graphical User does not have privileges to perform a X, R to specific roles and access level (HQ, specific region, specific User Interface) state), and sensitive data privileges. transaction. Note: ICIS does not have Batch-specific privileges. The privileges for Batch and Web access are the same. Compliance Schedule Key Elements CS030 The combination of Enforcement Action Identifier, Final Order GUI The combination of Enforcement Action Identifier, Final X Identifier, NPDES ID, and Compliance Schedule Number must Order Identifier, Permit Identifier, and Compliance exist in ICIS. Schedule Number must already exist in ICIS. CS031 The existing Enforcement Action in ICIS must be a state Activity GUI The Enforcement Action in ICIS must represent a State X, R (i.e., state_epa_flag = S) in the ICIS_ACTIVITY table. Enforcement Action. CS040 The NPDES ID must exist in ICIS and must be a linked Facility GUI The Permit Identifier must already exist in ICIS and R Interest for the Final Order. must be linked to the Final Order. Note: This business rule is not checked for Replace transactions where the Compliance Schedule exists in ICIS.

Error/ Business Rules Where Error/Warning Message Applicable Warning Enforced Transaction Code (Web) Types CS041 The combination of Enforcement Action Identifier and Final Order GUI The combination of Enforcement Action Identifier and R Identifier must exist in ICIS. Final Order Identifier must already exist in ICIS. Note: This business rule is not checked for Replace transactions where the Compliance Schedule exists in ICIS. Compliance Schedule Data Elements CS050 A Compliance Schedule must include one or more Compliance Business rule The Compliance Schedule must include one or more R Schedule Events. layer Compliance Schedule Events. CS070 For a Schedule Descriptor Code, the narrative_condition_code GUI Schedule Descriptor Code does not exist or is inactive in the ICIS reference REF_NARRATIVE_CONDITION table. table. Compliance Schedule Event Data Elements CS080 For each Compliance Schedule, the combination of Schedule Business rule The Schedule Event must be unique for the Compliance Schedule.

Note: This error message is only issued once for duplicate Schedule Events. CS090 Schedule Event Code must be a valid (i.e., Active) code in the GUI For the Schedule Event , Schedule Event Code does not exist or is inactive in the ICIS reference table.

Note: This error message is issued once for each Schedule Event. CS100 Report Received Date must exist if Actual Date exists. Business rule For the Schedule Event , Schedule Report Received Date must exist because Schedule Actual Date exists.

Note: This error message is issued once for each Schedule Event.

Error/ Business Rules Where Error/Warning Message Applicable Warning Enforced Transaction Code (Web) Types CS110 Report Received Date must be greater than or equal to Actual Business rule For the Schedule Event , Schedule Report Received Date must be greater than or equal to Schedule Actual Date .

Note: This error message is issued once for each Schedule Event. CS120 Report Received Date must be less than or equal to the current Business rule For the Schedule Event , Schedule Report Received Date must be less than or equal to the current date .

Note: This error message is issued once for each Schedule Event. CS130 Actual Date must be less than or equal to the current date. Business rule For the Schedule Event , Schedule Actual Date must be less than or equal to the current date .

Note: This error message is issued once for each Schedule Event. CS140 The Compliance Schedule Penalty Amount cannot be entered Business rule For the Schedule Event , Compliance Schedule Penalty CS001, CS002, CS003, or CS033. Amount cannot be entered because Schedule Event Code is not one of the following: CS001, CS002, CS003, or CS033.

Note: This error message is issued once for each Schedule Event. Background Processing CS150 If Background Processing does not complete successfully for a N/A An error has occurred while processing data for this X, R Compliance Schedule transaction, roll back all changes for the Compliance Schedule, no data was deleted or saved XML transaction. and the XML transaction must be resubmitted.

3. DATA ELEMENT MAPPING

The mapping between PCS Acronym, XML Tag Name, ICIS Screen Name, and ICIS Database Name is shown below in Table 3-14: Batch Compliance Schedule Data Element Mapping. The table is organized according to the order in which tags are listed in the Compliance Schedule schema.

Table 3-14: Batch Compliance Schedule Data Element Mapping

PCS Acronym XML Tag Name XML Data Type ICIS Screen Name ICIS Database Name Compliance Schedule Key Elements N/A EnforcementActionIdenti icis:StringMin1Max20TypeBase Enforcement Action Identifier icis_enforcement.enf_identifier fier N/A FinalOrderIdentifier icis:IntegerRange1To99999Type Final Order ID icis_enf_conclusion.enf_conclusion_nmbr NPID PermitIdentifier icis:String9FixedTypeBase NPDES ID icis_facility_interest.pgm_sys_id CSCH ComplianceScheduleNu icis:Integer2FixedRange1To999Typ Schedule Number icis_comp_schedule.comp_schedule_nmbr mber eBase Compliance Schedule Elements N/A ComplianceScheduleCo icis:StringMin1Max4000Type Comments icis_comp_schedule.compliance_schedule_comment mments _text N/A ScheduleDescriptorCod icis:StringMin1Max3Type Schedule Descriptor icis_comp_schedule.narrative_condition_code e Compliance Schedule Event Elements EVNT ScheduleEventCode icis:StringMin1Max5TypeBase Event icis_comp_schedule_event.schedule_event_code DTSC ScheduleDate icis:DateType Schedule Date icis_comp_schedule_event.schedule_date DTRC ScheduleReportReceive icis:DateType Report Received Date icis_comp_schedule_event.report_received_date dDate DTAC ScheduleActualDate icis:DateType Actual Date icis_comp_schedule_event.actual_date DTAC ScheduleProjectedDate icis:DateType Projected Date icis_comp_schedule_event.projected_date RDC1 ScheduleUserDefinedDaicis:StringMin1Max30Type User Defined 1 icis_comp_schedule_event.udf1 taElement1 RDC2 ScheduleUserDefinedDaicis:StringMin1Max30Type User Defined 2 icis_comp_schedule_event.udf2 taElement2

PCS Acronym XML Tag Name XML Data Type ICIS Screen Name ICIS Database Name N/A ScheduleEventCommenticis:StringMin1Max4000Type Comments icis_comp_schedule_event.comment_text s N/A ComplianceSchedulePe icis:DecimalRange0To9999999999 Amount icis_comp_schedule_event.event_amt naltyAmount 99.99Type

4. XML SCHEMA

The following sections of the ICIS XML schema are related to the Compliance Schedule Submission Type:

• ICIS_Common.xsd • ICIS_Header.xsd • ICIS_Key_Elements.xsd • ICIS_ComplianceSchedule.xsd • ICIS_ScheduleEvent.xsd

APPENDIX A: ACRONYMS

Table A-15: Acronym List

Acronym Definition BGP Background Processing CDX Central Data Exchange DB Database DMR Discharge Monitoring Report EPA Environmental Protection Agency GUI Graphic User Interface ICIS Integrated Compliance Information System NPDES National Pollutant Discharge Elimination System PCS Permit Compliance System RNC Reportable Non-compliance XML Extensible Markup Language

35 ICIS Batch – Compliance Schedule, Version 1.2