Office of Enforcement and Compliance Assurance
Integrated Compliance Information System
ICIS Batch
Master General Permit – Technical Specification
Version 1.5
Revised Final
October 6, 2011
Office of Enforcement and Compliance Assurance
Document Change History
Version Number
Date
Description
0.1
October 13, 2009
Initial Draft Release
1.0
November 10, 2009
• Incorporated comments provided by EPA
• Incorporated consistency change on Replace flow to
clarify Replace (like New) and Replace (like Change).
• Changed error message for Business Rule 35 to “A
Permit Component Storm Water Medium/Large MS4s
is not valid for a Master General Permit.”
1.1
July 16, 2010
• Updated Permit Status flow to check for Terminated
Permits.
• Added BR 37 to prevent a Terminated Permit Status
from being changed.
• Added BR 38 to prevent Permit Type from being
blanked out.
• Changed Error/Warning Codes for Business Rules 1
and 2 from MGP010, MGP020 to BAT010, BAT020 for
consistency with other Technical Specifications.
• Added missing parentheses to Business Rule 28.
• Updated Error Messages for BR 16 and 17 for
consistency with the Permit Basic Information
Technical Specification (BR31 and 32).
• Updated Technical Specification Text for Business
Rule Row ID to just ID for consistency with other
Technical Specifications.
• Updated BR 15 (MGP160) to remove check for MPED
less than Permit Expiration Date.
• Changed BR 11 and 19 and accompanying Error
Messages to account for editable Permit Issue Date
Change Request (CR441).
• Changed BR 16 to account for editable Permit Issue
Date Change Request (CR441).
• Changed Permit Tracking Event flow to account for
CR441; Permit Issued PTE is changed when Permit
Issue Date is changed; Original Permit Issue Date is
changed when only one version of the Permit exists.
1.2
December 22, 2010
Added Delete Master General Permit Functionality.
1.3
January 21, 2011
Incorporated comments provided by EPA.
1.4
July 29, 2011
• Mapped MGP070 to Delete in business rule table and
flow.
• Added a note to reference O&M DRs 7954 and 7955
above the flow Process Data for Resetting Previous
Version of Permit to Current Version.
• Changed < to <= in step 4 of the Process Data for
Resetting Previous Version of Permit to Current
Version. Also updated supporting table.
• Changed “Phase” to “Release” in Introduction.
• Updated the document for O&M CR 566. Unmapped
MGP380 (ID 39) from Delete transactions where a
previous version of the Permit exists. This rule relates
to deleting an MGP if it has any linked GPCFs.
• Clarified the text that explains default values in Section
2.1.3. Clarified that default values apply to New,
Change, and Replace transactions. Clarified that if a
i
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Version Number
1.5
Date
October 6, 2011
Description
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.
• Clarified the text in the Introduction which describes
the current users of ICIS.
•
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.
ii
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table of Contents
1. INTRODUCTION..................................................................................................................... 1
1.1 PURPOSE ................................................................................................................................ 2
1.2 ASSUMPTIONS AND CONSTRAINTS .......................................................................................... 2
1.3 DOCUMENT OVERVIEW ........................................................................................................... 3
2. VALIDATION AND PROCESSING ...................................................................................... 4
2.1 GENERAL BATCH PROCESSING RULES ................................................................................... 4
2.1.1 Asterisks ......................................................................................................................... 4
2.1.2 Multi-Value Items .......................................................................................................... 4
2.1.3 Default Values ............................................................................................................... 7
2.2 DELETE (D) MASTER GENERAL PERMIT PROCESSING ............................................................ 7
2.2.1 Delete Master General Permit Processing Flow ............................................................ 8
2.2.2 Process Data for Resetting Previous Version of Permit to Current Version ............... 13
2.2.3 Delete Master General Permit Sample Scenarios ........................................................ 18
2.3 NEW (N) MASTER GENERAL PERMIT PROCESSING............................................................... 19
2.3.1 New Master General Permit Processing Flow ............................................................. 20
2.3.2 Generate Permit Status Flow ....................................................................................... 24
2.3.3 Process Permit Tracking Event Data Flow .................................................................. 27
2.3.4 New Master General Permit Sample Scenarios ........................................................... 30
2.4 CHANGE (C) MASTER GENERAL PERMIT PROCESSING ......................................................... 31
2.4.1 Change Master General Permit Processing Flow ........................................................ 31
2.4.2 Change Master General Permit Sample Scenarios ...................................................... 35
2.5 REPLACE (R) MASTER GENERAL PERMIT PROCESSING ........................................................ 36
2.5.1 Replace Master General Permit Processing Flow ........................................................ 37
2.5.2 Replace Master General Permit Sample Scenarios ...................................................... 41
2.6 BUSINESS RULES .................................................................................................................. 43
3. DATA ELEMENT MAPPING .............................................................................................. 53
4. XML SCHEMA ....................................................................................................................... 55
APPENDIX A: ACRONYMS .................................................................................................... 56
iii
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
List of Tables
Table 2-1: Adding to a Multi-Value Item List ................................................................................ 5
Table 2-2: Changing to a Multi-Value Item List ............................................................................ 6
Table 2-3: Deleting from a Multi-Value Item List ......................................................................... 6
Table 2-4: Delete Master General Permit Processing ................................................................... 10
Table 2-5: Process Data for Resetting Previous Version of Permit to Current Version ............... 15
Table 2-6: Delete Master General Permit Example 1 ................................................................... 18
Table 2-7: Delete Master General Permit Example 2 ................................................................... 18
Table 2-8: Delete Master General Permit Example 3 ................................................................... 19
Table 2-9: Delete Master General Permit Example 4 ................................................................... 19
Table 2-10: New Master General Permit Processing .................................................................... 22
Table 2-11: Generate Permit Status .............................................................................................. 25
Table 2-12: Process Permit Tracking Event Data ......................................................................... 28
Table 2-13: New Master General Permit Example 1 .................................................................... 30
Table 2-14: New Master General Permit Example 2 .................................................................... 31
Table 2-15: New Master General Permit Example 3 .................................................................... 31
Table 2-16: Change Master General Permit Processing ............................................................... 33
Table 2-17: Change Master General Permit Example 1 ............................................................... 35
Table 2-18: Change Master General Permit Example 2 ............................................................... 36
Table 2-19: Change Master General Permit Example 3 ............................................................... 36
Table 2-20: Replace Master General Permit Processing .............................................................. 39
Table 2-21: Replace Master General Permit Example 1 .............................................................. 41
Table 2-22: Replace Master General Permit Example 2 .............................................................. 41
Table 2-23: Replace Master General Permit Example 3 .............................................................. 42
Table 2-24: Replace Master General Permit Example 4 .............................................................. 42
Table 2-25: Batch Master General Permit Business Rules ........................................................... 43
Table 3-1: Master General Permit Data Element Mapping .......................................................... 53
Table A-1: Acronym List .............................................................................................................. 56
iv
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
List of Figures
Figure 2-1: Delete Master General Permit Processing Flow .......................................................... 9
Figure 2-2: Process Data for Resetting Previous Version of Permit to Current Version ............. 14
Figure 2-3: New Master General Permit Processing Flow ........................................................... 21
Figure 2-4: Generate Permit Status ............................................................................................... 24
Figure 2-5: Process Permit Tracking Event Data ......................................................................... 27
Figure 2-6: Change Master General Permit Processing Flow ...................................................... 32
Figure 2-7: Replace Master General Permit Processing Flow ...................................................... 38
v
ICIS Batch – Master General Permit Technical Specification, Version 1.5
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 Master General Permit module is part of Full Batch Release 1.
The focus of this technical specification is the submission of the current version of Master
General Permit data to ICIS through Master General Permit XML transactions. Data for other
parts of the permit (e.g. Permit Schedules, Limit Sets, Limits), other types of permits (e.g.,
Individual Permits), and Permit Reissuance will be addressed in separate technical specifications.
The general process for states to submit batch data was previously 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.
•
“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.
1
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
A batch may contain many XML files, and within each XML file there can be up to one Payload
for each Submission Type (e.g., MGP). Each Payload may contain one or many XML
transactions, each of which contains the Permit data and a specific transaction type that identifies
how ICIS should process the data. For the Master General Permit Submission Type, there are
four valid XML transaction types: Delete, New, Change, and Replace. The details of the Master
General Permit XML transaction type are described in Section 2: Validation and Processing.
After receiving a batch from CDX, ICIS parses it and saves each Master General Permit XML
transaction to the database so that the individual 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 that processing is complete.
1.1 PURPOSE
The purpose of this document is to provide a comprehensive overview of the submission of
Master General Permit data through batch XML transactions using text descriptions, tables, and
figures.
A major component of this Master General Permit Technical Specification, Section 2: Validation
and Processing, details the four valid transaction types (Delete, New, Change, and Replace) for
Master General Permit submissions. Provided with these transactions are the business rules that
govern batch Master General Permit 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.
1.2 ASSUMPTIONS AND CONSTRAINTS
The following assumptions and constraints apply to the ICIS Batch Master General Permit
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 Master General Permits entered via batch should be the same as
Master General Permits entered via the web application. Any differences will be noted in the
“Where Enforced (Web)” and “Where Enforced (Batch)” Columns of the Business Rules
table in Section 2: Validation and Processing.
2
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
•
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.
1.3 DOCUMENT OVERVIEW
The following sections comprise the remainder of this technical specification:
•
Section 2: Validation and Processing – This section describes the processing of Delete,
New, Change, and Replace Master General Permit 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 Master General Permit data elements.
•
Section 4: XML Schema – This section provides a list of the XML schemas related to
Master General Permit.
•
Appendix A: Acronyms – This section provides a list of all acronyms used in the document.
•
Attachment A: Contacts and Addresses – This attachment provides the Business Rules and
Data Element Mapping for the Contacts & Addresses (CA) data.
3
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2. VALIDATION AND PROCESSING
After receiving a batch from CDX, ICIS parses the batch into individual Master General Permit
XML transactions, saves each to the database, and groups them by type. The valid transaction
types for Master General Permit are Delete, New, Change, 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 details the processing order
for all ICIS Full Batch Submissions. This section describes the detailed processing of the four
Master General Permit transaction types.
Master General Permits are written to cover a multitude of facilities that share specific
characteristics. They are not written for a single facility. For this reason, a Master General Permit
does not have a linked Facility Interest. Facilities covered by the Master General Permit may
have a General Permit Covered Facility permit record in ICIS. Since a Master General Permit
does not have a linked Facility Interest, it generally has only a subset of the data that exists for an
Individual Permit (e.g., Non-Government Addresses do not exist). Similarly, compliance is not
evaluated, so there is no background processing for a Master General Permit.
The following sub-sections describe general processing rules related to asterisks and multi-value
items and the detailed processing of Master General Permit XML transactions.
2.1 GENERAL BATCH PROCESSING RULES
It is important to understand the following general batch processing rules for ICIS:
2.1.1 Asterisks
Users must have the ability to remove data from fields through batch transactions. This is
accomplished through the use of asterisks (*). In a Change transaction, an asterisk in a tag for an
optional field is used to indicate that the field should be blanked out. Asterisks in a combination
of mandatory and optional tags are also used to remove sub-sections of a record from ICIS,
which is described in detail in Section 2.1.2 Multi-Value Items. 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 New and Replace transactions. When that happens, they are interpreted by
the system as blanks. It is not necessary for the user to submit asterisks in New and 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.
2.1.2 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. There are two categories of multi-value
items:
4
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Individual Data Tag – The simplest kind of multi-value item consists of one data tag that can be
repeated multiple times within a transaction. Below is an example of a Master General Permit –
Permit Component Type Code Data Tag multi-value item (PermitComponentTypeCode)
repeated multiple times:
<PermitComponentTypeCode>PRE</PermitComponentTypeCode>
<PermitComponentTypeCode>CAF</PermitComponentTypeCode>
<PermitComponentTypeCode>CSO</PermitComponentTypeCode>
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 of a Master General Permit
multi-value item (OtherPermits) repeated multiple times:
<OtherPermits>
<OtherPermitIdentifier>VA123</OtherPermitIdentifier>
<OtherOrganizationName>Department of Health</OtherOrganizationName>
<OtherPermitIdentifierContextName>Well permit</OtherPermitIdentifierContextName>
</OtherPermits>
<OtherPermits>
<OtherPermitIdentifier>VAA1098</OtherPermitIdentifier>
<OtherOrganizationName>County Government</OtherOrganizationName>
<OtherPermitIdentifierContextName>Well permit</OtherPermitIdentifierContextName>
</OtherPermits>
If data already exist for one of these multi-value items for the Permit 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
PermitComponentTypeCode in ICIS PermitComponentTypeCode in XML Result in ICIS DB After Processing
DB
Submission
PRE
PRE
PRE
CAF
CAF
CAF
CSO
CSO
If data already exist for one of these multi-value items for the Permit 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.
5
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-2: Changing to a Multi-Value Item List
PermitComponentTypeCode in ICIS PermitComponentTypeCode in XML Result in ICIS DB After Processing
DB
Submission
PRE
PRE
PRE
CSO
CSO
CAF
If data already exist for one of these multi-value items for the Permit 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 value they wish to keep) in their XML submission. The table below
provides an example.
Table 2-3: Deleting from a Multi-Value Item List
PermitComponentTypeCode in ICIS PermitComponentTypeCode in XML Result in ICIS DB After Processing
DB
Submission
PRE
PRE
PRE
CAF
CSO
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 multivalue 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.
6
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
•
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 Master General Permit schema contains the following multi-value items:
•
•
•
•
•
•
OtherPermits
AssociatedPermit
SICCodeDetails
NAICSCodeDetails
Contact – a subsection of PermitContact
PermitComponentTypeCode
2.1.3 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 EDMR Authorization Flag cannot be entered through batch transactions. ICIS generates a
value of No for this field, even though this field only appears in the database for Master General
Permits. There are other system-generated fields whose values are determined by complex logic
that are explained in the sub-process flow diagrams later in this document.
2.2 DELETE (D) MASTER GENERAL PERMIT PROCESSING
The Delete Master General Permit XML transaction allows the user to remove a Master General
Permit as well as any child Permit records and links (i.e., Permitted Features, Limit Sets, Limits,
Narrative Conditions, Permit Schedules, Permit Tracking Events, Non-Government Contacts,
and Links to Government Contacts) from ICIS.
7
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Business Rules for deleting a Master General Permit will vary when the current version of the
Permit is the only version and no previous versions exist versus a Reissued Permit (i.e., the
current version of the Permit has previous versions that exist).
The processing of a Delete Master General Permit XML transaction in ICIS is described below.
Also included in this section are sample Delete Master General Permit scenarios.
2.2.1 Delete Master General Permit Processing Flow
Figure 2-1: Delete Master General Permit Processing Flow is a diagram depicting the processing
of a Delete Master General Permit transaction. There is a sub-flow that is called in the Delete
Master General Permit Processing Flow when the Permit being deleted has a previous version.
Figure 2-2: Process Data for Resetting Previous Version of Permit to Current Version will update
the most recent previous version of the Permit that becomes the current version when a Reissued
Permit is deleted. A table detailing each step in the flow diagram is also included in this section.
8
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Figure 2-1: Delete Master General Permit Processing Flow
9
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-4: Delete Master General Permit Processing contains a description of the items in the above Delete Master General Permit
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 Master General Permits can be found in Table 2-25: Batch Master
General Permit Business Rules.
Table 2-4: Delete Master General Permit Processing
Item
Number
Item Description
Mapping To Business Rule Table
1
Does Permit exist in ICIS?
ID 6
ICIS determines if the NPDES ID exists for the Permit. If the NPDES ID does not exist, processing continues
at #1A; otherwise processing continues at #2.
1A
Reject transaction. Write 1 error message to the error log.
ICIS has determined that a Permit does not exist with the submitted NPDES ID. ICIS rejects the entire XML
transaction and processing ends.
2
Does user have privileges to perform Delete Master General Permit XML transaction?
ID 2
ICIS determines if the User ID that has submitted this Delete Master General Permit XML transaction has the
correct privileges defined in ICIS. This includes determining if the user can perform a Delete Master General
Permit transaction and if the Permit is in a state/region for which the user has authority. 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 Master General Permit function, which is available as part of the Master General Permit
Deletion role. If the ICIS User ID has the correct privileges, processing continues at #3; otherwise processing
continues at #2A.
2A
Reject transaction. Write 1 error message to the error log.
ICIS has determined that the User ID does not have the correct privileges. ICIS rejects the entire XML
transaction and processing ends.
3
Does Permit have a previous version?
N/A
If ICIS determines a previous version of the Permit exists for the submitted NPDES ID, processing continues
at #4; otherwise processing continues at 3A.
3A
Are data valid for Delete Permit with no previous version?
IDs 7, 39- 41
ICIS checks business rules identified in the Mapping to Business Rule Table column to determine if the data
are valid. If none of the business rules are violated, processing continues at #3B; otherwise processing
continues at #3A1.
3A1
Reject transaction. Write 1 error message per business rule violation to the error log.
IDs 7, 39- 41
If ICIS determines the data are invalid, ICIS rejects the entire Delete Master General Permit XML transaction.
ICIS writes an error message to the error log for each business rule violation and processing of this Delete
Master General Permit XML transaction ends.
ID 6
ID 2
10
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
3B
Delete Permit.
ICIS has determined that the Permit is valid for deletion. The Permit, including all of its child records, is
deleted, and processing continues at #3C.
3C
Is there a Reissuance in Progress for Permit Just Deleted?
N/A
If ICIS determines there is a Reissuance in Progress for the Permit, processing continues at #3C1; otherwise,
processing continues at #3D.
3C1
Delete Reissuance in Progress.
ICIS has determined that there is a Reissuance in Progress for the Permit. The Reissuance in Progress is
deleted, and processing continues at #3D.
N/A
3D
Accept Transaction.
ICIS logs an accepted Delete Master General Permit transaction. Processing of this Delete Master General
Permit XML transaction ends.
N/A
4
Are data valid for Delete Reissued Permit?
IDs 7, 41
ICIS checks business rules identified in the Mapping to Business Rule Table column to determine if the data
are valid. If none of the business rules are violated, processing continues at #5; otherwise processing
continues at #4A.
4A
Reject transaction. Write 1 error message per business rule violation to the error log.
If ICIS determines that data are invalid, ICIS rejects the entire Delete Master General Permit XML
transaction. ICIS writes an error message to the error log for each business rule violation and processing of
this Delete Master General Permit XML transaction ends.
IDs 7, 41
5
Delete Reissued Permit.
ICIS has determined that the Permit is valid for deletion. The Reissued Permit, including all of its child
records, is deleted, and processing continues at #6.
N/A
N/A
Note: O&M DR 7507 exists for an unexpected error when attempting to delete the current version of a
reissued Master General Permit.
6
Is there a Reissuance in Progress for Reissued Permit Just Deleted?
N/A
If ICIS determines there is a Reissuance in Progress for the Permit, processing continues at #6A; otherwise,
processing continues at #7.
6A
Delete Reissuance in Progress.
ICIS has determined that there is a Reissuance in Progress for the Permit. The Reissuance in Progress is
deleted, and processing continues at #7.
7
Save Most Recent Previous Version of Reissued Permit as Current Version.
N/A
ICIS saves the most recent previous version of the Reissued Permit (version 1) as the current version of the
Permit and sets the Version Number for the Permit to 0. Processing continues at #8.
N/A
11
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
8
Process Data for Resetting Previous Version of Permit to Current Version (Figure 2-2)
ICIS continues processing at Table 2-5: Process Data for Resetting Previous Version of Permit to Current
Version and then processing continues at #9.
N/A
9
Accept Transaction.
ICIS logs an accepted Delete Master General Permit transaction. Processing of this Delete Master General
Permit XML transaction ends.
N/A
12
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.2.2 Process Data for Resetting Previous Version of Permit to Current Version
Figure 2-2: Process Data for Resetting Previous Version of Permit to Current Version depicts the
process of updating the most recent previous version of the Permit to the current version of the
Permit. A table detailing each step in the Process Data for Resetting Previous Version of Permit
to Current Version is also included in this section.
The ICIS Web Permit Basic Information technical specification and the ICIS Web application
currently do not differentiate between Master General Permits and other Permit Types when
generating the Permit Status for a deleted Reissued permit. The Batch processing will not
function correctly until the ICIS Web defects are resolved. For more information, see O&M DRs
7954 and 7955.
13
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Figure 2-2: Process Data for Resetting Previous Version of Permit to Current Version
14
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-5: Process Data for Resetting Previous Version of Permit to Current Version contains a description of the items in the above
Process Data for Resetting Previous Version of Permit to Current Version 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 business rules relating to
Generate Permit Status can be found in Table 2-25: Batch Master General Permit Business Rules.
Table 2-5: Process Data for Resetting Previous Version of Permit to Current Version
Item
Number
Item Description
Mapping To Business Rule Table
1
Does a Retirement Date from the Previous Version of Permit Becoming Current Version exist?
If ICIS determines a Retirement Date from the previous version of the Permit becoming the current version
exists, processing continues at #1A; otherwise, processing continues at #2.
N/A
1A
Delete Retirement Date from the Previous Version of Permit Becoming Current Version.
ICIS deletes the Retirement Date from the previous version of Permit becoming the current version, and
processing continues at #2.
N/A
2
Do Permit Tracking Events “Permit Retired” and “Permit Reissued” Exist from the Previous
Version of Permit Becoming Current Version?
If ICIS determines Permit Tracking Events “Permit Retired” and “Permit Reissued” exist from the previous
version of the Permit becoming the current version, processing continues at 2A; otherwise processing
continues at #3.
N/A
2A
Delete Permit Tracking Events “Permit Retired” and “Permit Reissued” from the Previous Version
of Permit Becoming Current Version.
ICIS has determined the Permit Tracking Events from the previous version of the Permit becoming the
current version equal Permit Retired and Permit Reissued. ICIS deletes the Permit Tracking Event(s),
including the Permit Tracking Event Code, Permit Tracking Event Date, and Permit Tracking Event
Comments. Processing continues at #3.
N/A
3
Is Current Date >= Permit Effective Date AND is Current Date <= Permit Expiration Date?
If ICIS determines the Current Date is greater than or equal to the Permit Effective Date of the previous
version of the Permit becoming the current version and if the Current Date is less than or equal to the
Permit Expiration Date of the previous version of the Permit becoming the current version, processing
continues at #3A; otherwise processing continues at #4.
N/A
3A
Set Permit Status to Effective.
ICIS has determined the Current Date is greater than or equal to the Permit Effective Date of the previous
version of the Permit becoming the current version and the Current Date is less than or equal to the Permit
Effective Date of the previous version of the Permit becoming the current version. ICIS sets the Permit
Status to Effective, and processing continues at #3B.
N/A
15
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
3B
Return to calling program.
After setting the Permit Status to Effective, ICIS returns to the calling program (Table 2-4: Delete Master
General Permit Processing (#9)).
N/A
4
Is Current Date > Permit Expiration Date AND is Current Date <= Permit Expiration Date + 90 Days?
If ICIS determines the Current Date is greater than the Permit Expiration Date of the previous version of
the Permit becoming the current version and the Current Date is less than or equal to the Permit Expiration
Date of the new version of the Permit plus 90 days, processing continues at #4A; otherwise processing
continues at #5.
N/A
4A
Set Permit Status to Administratively Continued.
ICIS has determined the Current Date is greater than the Permit Expiration of the previous version of the
Permit becoming the current version and the Current Date is less than or equal to the Permit Expiration
Date of the previous version of the Permit becoming the current version plus 90 days. ICIS sets the Permit
Status to Administratively Continued, and processing continues at #4B.
N/A
4B
Return to calling program.
After setting the Permit Status to Administratively Continued, ICIS returns to the calling program (Table
2-4: Delete Master General Permit Processing (#9)).
N/A
5
Is Current Date > Permit Expiration Date + 90 days AND is Application Received Date or Complete
Application Received Date >= Permit Effective Date?
If ICIS determines the Current Date is greater than the Permit Expiration Date of the previous version of
the Permit becoming the current version plus 90 days and the Application Received Date or the Complete
Application Received Date of the previous version of the Permit becoming the current version is greater
than or equal to the Permit Effective Date, processing continues at #5A; otherwise processing continues at
#6.
N/A
5A
Set Permit Status to Administratively Continued.
ICIS has determined the Current Date is greater than the Permit Expiration Date of the previous version of
the Permit becoming the current version plus 90 days and the Application Received Date or the Complete
Application Received Date of the previous version of the Permit becoming the current version is greater
than or equal to the Permit Effective Date. ICIS sets the Permit Status to Administratively Continued, and
processing continues at #5B.
N/A
5B
Return to calling program.
After setting the Permit Status to Administratively Continued, ICIS returns to the calling program (Table
2-4: Delete Master General Permit Processing (#9)).
N/A
16
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
6
Set Permit Status to Expired.
ICIS has determined the Current Date is greater than the Permit Expiration Date of the previous version of
the Permit becoming the current version plus 90 days and neither the Application Received Date nor
Complete Application Received Date is greater than or equal to the Permit Effective Date of the previous
version of the Permit becoming the current version. ICIS sets the Permit Status Permit to Expired, and
processing continues at #7.
N/A
7
Return to calling program.
After setting the Permit Status to Administratively Continued, ICIS returns to the calling program (Table
2-4: Delete Master General Permit Processing (#9)).
N/A
17
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.2.3 Delete Master General Permit Sample Scenarios
A Delete Master General Permit transaction should contain only key data (i.e., NPDES ID),
though if it contains any other data (i.e., any other tags that are not key tags), ICIS will still
process the Delete transaction and ignore the other data. However, if the transaction violates any
business rules, the permit cannot be deleted. Examples of possible Delete Master General Permit
scenarios are described below.
Example 1
If the submitted Delete Master General Permit XML includes:
•
•
Valid NPDES ID for a Permit with no previous version
Valid data
ICIS will accept the Delete Master General Permit XML transaction and remove the Permit and
any child Permit records from the database. Table 2-6: Delete Master General Permit Example 1
provides an example.
Table 2-6: Delete Master General Permit Example 1
MGP Data in ICIS DB
NPDES ID NY0000001
MGP XML Submission
Result in ICIS DB After Processing
Delete valid for Master General Permit
Child Permit records
Example 2
If the submitted Delete Master General Permit XML includes:
•
•
Valid NPDES ID for a Permit with a previous version (i.e., a Reissued Permit)
Valid Data
ICIS will accept the Delete Master General Permit XML transaction and remove the Permit and
any child Permit records from the database. ICIS will save the previous version of the Permit as
the current version. Table 2-7: Delete Master General Permit Example 2 provides an example.
Table 2-7: Delete Master General Permit Example 2
MGP Data in ICIS DB
Reissued NPDES ID NY0000002
(version 0)
MGP XML Submission
Result in ICIS DB After Processing
Delete valid for Master General Permit NPDES ID NY0000002 (version 1
becomes version 0)
Previous version of NPDES ID
NY0000002 (version 1)
Child Permit Records of NPDES ID
NY0000002 version 1 that becomes
version 0
Child Permit Records of reissued
NPDES ID NY0000002 (version 0)
18
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
Child Permit Records of previous
version of NPDES ID NY0000002
(version 0)
Example 3
If the submitted Delete Master General Permit XML includes:
•
•
Valid NPDES ID for a Permit with no previous version
Data that violates a business rule (e.g., NPDES ID has linked GPCF)
ICIS will reject the Delete Master General Permit XML transaction because the Permit has a
linked GPCF. Table 2-8: Delete Master General Permit Example 3 provides an example.
Table 2-8: Delete Master General Permit Example 3
MGP Data in ICIS DB
NPDES ID NY0000003
MGP XML Submission
Delete invalid for Master General
Permit
Result in ICIS DB After Processing
NPDES ID NY0000003
Linked GPCF
Linked GPCF
Child Permit Records
Child Permit Records
Example 4
If the submitted Delete Master General Permit XML includes:
•
•
Valid NPDES ID
Data that violates a business rule (e.g., NPDES ID is listed as Associated NPDES Permit for
another Permit
ICIS will reject the Delete Master General Permit XML transaction because it is listed as an
Associated NPDES Permit for another Permit. Table 2-9: Delete Master General Permit Example
4 provides an example.
Table 2-9: Delete Master General Permit Example 4
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID NY0000004 listed as
Delete invalid for Master General
Associated NPDES Permit for NPDES Permit
ID NY0000005
NPDES ID NY0000004 listed as
Associated NPDES Permit for NPDES
ID NY0000005
Child Permit Records
Child Permit Records
2.3 NEW (N) MASTER GENERAL PERMIT PROCESSING
The New Master General Permit XML transaction allows the user to create a new Master
General Permit in ICIS. The processing of a New Master General Permit XML transaction is
described below. Also included in this section are sample New Master General Permit scenarios.
19
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.3.1 New Master General Permit Processing Flow
Figure 2-3: New Master General Permit Processing Flow is a diagram depicting the processing
of a New Master General Permit XML transaction. There are several sub-flows that are called
during the New Master General Permit Processing Flow. Generate Permit Status (Figure 2-4)
will generate the Status of the Permit following similar logic that is used on the web application.
Process Permit Tracking Event Data (Figure 2-5) creates or updates Permit Tracking Events for
the Permit. A table detailing each step in the flow diagram is also included in this section.
20
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Figure 2-3: New Master General Permit Processing Flow
21
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-10: New Master General Permit Processing contains a description of the items in the above New Master General Permit
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. Business rules relating to Contacts and Addresses, denoted with CA, can be found in Attachment A: ICIS
Batch Contacts and Addresses. All other business rules relating to Master General Permits can be found in Table 2-25: Batch Master
General Permit Business Rules.
Table 2-10: New Master General Permit Processing
Item
Number
Item Description
Mapping To Business Rule Table
1
Does Permit exist in ICIS?
ID 4
ICIS determines if the NPDES ID exists for the Permit. If the NPDES ID does not exist, processing continues
at #2; otherwise processing continues at #1A.
1A
Reject transaction. Write 1 error message to the error log.
ICIS has determined that a Permit exists with the submitted NPDES ID. ICIS rejects the entire XML
transaction, and processing of this New Master General Permit XML transaction ends.
2
Does user have privileges to perform New Master General Permit XML transaction?
ID 2
ICIS determines if the User ID that has submitted this New Master General Permit XML transaction has the
correct privileges defined in ICIS. This includes determining if the user can perform a Master General Permit
XML transaction and if the Permit is in a state/region for which the user has authority. 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 Master General Permit function, which is available as part of the Master General Permit Editor role. If the
ICIS User ID has the correct privileges, processing continues at #3; otherwise processing continues at #2A.
2A
Reject transaction. Write 1 error message to the error log.
ICIS has determined that the User ID does not have the correct privileges. ICIS rejects the entire XML
transaction, and processing of this New Master General Permit XML transaction ends.
ID 2
3
Generate Permit Status (Figure 2-4).
ICIS continues processing the data for the New Master General Permit XML transaction under Table 2-11:
Generate Permit Status. Processing continues at #4.
N/A
4
Are data valid?
ICIS checks the business rules identified in the Mapping to Business Rule Table column to determine if the
data are valid. If none of the business rules are violated, processing continues at #5; otherwise processing
continues at #4A.
IDs 5, 7, 9-14, 20-35, 38, CA IDs 1-9
4A
Reject transaction. Write 1 error message per business rule violation to the error log.
ICIS has determined that the data are not valid. ICIS rejects the entire XML transaction, and processing of
this New Master General Permit XML transaction ends.
IDs 5, 7, 9-14, 20-35, 38, CA IDs 1-9
ID 4
22
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
5
Process Permit Tracking Event Data (Figure 2-5).
N/A
ICIS continues processing at Table 2-12: Process Permit Tracking Event Data and then processing continues
at #6.
6
Save the Permit to the database.
N/A
ICIS inserts a New Master General Permit record and saves it to the database. It sets the Version Number for
the Master General Permit to 0. Processing continues at #7.
7
Accept Transaction.
ICIS logs an accepted New Master General Permit transaction. Processing of this New Master General
Permit XML transaction is complete.
N/A
23
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.3.2 Generate Permit Status Flow
Figure 2-4: Generate Permit Status is a sub-flow diagram depicting the generation of Permit
Status for the Permit. A table detailing each step in the flow is also included in this section.
Figure 2-4: Generate Permit Status
24
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-11: Generate Permit Status contains a description of the items in the above Generate Permit Status 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
business rules relating to Generate Permit Status can be found in Table 2-25: Batch Master General Permit Business Rules.
Table 2-11: Generate Permit Status
Item
Number
Item Description
Mapping To Business Rule Table
1
Does Permit Status equal Terminated?
If the Permit Status is equal to Terminated, processing continues at #1A; otherwise processing continues
at #2.
N/A
1A
Return to calling program.
After determining that Permit Status equals Terminated, ICIS returns to the calling program (Table 2-10:
New Master General Permit Processing (#4), Table 2-16: Change Master General Permit Processing (#5),
or Table 2-20: Replace Master General Permit Processing (#4 or #1C)).
N/A
2
Is Current Date less than Permit Effective Date or does Effective Date not exist?
If either the Current Date is less than the Permit Effective Date or the Effective Date does not exist,
processing continues at #2A; otherwise processing continues at #3.
N/A
2A
Set Permit Status to Pending.
ICIS has determined that the Permit Effective Date has not yet been reached or the Effective Date does
not exist. ICIS sets the Permit Status to Pending. Processing continues at #2B.
N/A
2B
Return to calling program.
After setting the Permit Status to Pending, ICIS returns to the calling program (Table 2-10: New Master
General Permit Processing (#4), Table 2-16: Change Master General Permit Processing (#5), or Table
2-20: Replace Master General Permit Processing (#4 or #1C)).
N/A
3
Is Current Date less than or equal to Permit Expiration Date?
ICIS has determined the Current Date is greater than or equal to the Permit Effective date. If the Current
Date is less than or equal to the Permit Expiration Date, processing continues at #3A; otherwise
processing continues at #4.
N/A
3A
Set Permit Status to Effective.
ICIS has determined that the Expiration Date has not yet been reached. ICIS sets the Permit Status to
Effective. Processing continues at #3B.
N/A
3B
Return to calling program.
After setting the Permit Status to Effective, ICIS returns to the calling program (Table 2-10: New Master
General Permit Processing (#4), Table 2-16: Change Master General Permit Processing (#5), or Table
2-20: Replace Master General Permit Processing (#4 or #1C)).
N/A
25
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
4
Set Permit Status to Administratively Continued.
ICIS has determined that the Current Date is greater than the Expiration Date. ICIS sets the Permit status
to Administratively Continued. Processing continues at #5.
N/A
5
Return to calling program.
After setting the Permit Status to Administratively Continued, ICIS returns to the calling program (Table
2-10: New Master General Permit Processing (#4), Table 2-16: Change Master General Permit Processing
(#5), or Table 2-20: Replace Master General Permit Processing (#4 or #1C)).
N/A
26
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.3.3 Process Permit Tracking Event Data Flow
Figure 2-5: Process Permit Tracking Event Data is a sub-flow diagram depicting the processing
of Permit Tracking Event (PTE) data based on other fields entered for the Permit. A table
detailing each step in the flow is also included in this section.
Figure 2-5: Process Permit Tracking Event Data
27
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-12: Process Permit Tracking Event Data contains a description of the items in the above Process Permit Tracking Event Data
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 business rules relating to Permit Tracking Event Data can be found in Table 2-25: Batch Master General
Permit Business Rules.
Table 2-12: Process Permit Tracking Event Data
Item
Number
Item Description
Mapping To Business Rule Table
1
Is Permit Issue Date entered?
ICIS determines if Permit Issue Date was entered in the batch. If the Permit Issue Date was entered,
processing continues at #1A; otherwise processing continues at #2.
N/A
1A
Does a Permit Issued Permit Tracking Event exist in ICIS?
ICIS has determined the Permit Issue Date has been entered in the batch. ICIS determines if a Permit
Issued Permit Tracking Event exists in ICIS. If the Permit Issued Permit Tracking Event exists, processing
continues at #1B; otherwise processing continues at #1A1.
N/A
1A1
Create a Permit Issued Tracking Event and set the PTE Date to the Permit Issue Date and set the
PTE Comments to System generated value.
ICIS has determined a Permit Issued Permit Tracking Event does not exist in ICIS. ICIS creates a Permit
Issued Permit Tracking Event with PTE Date set to the Permit Issue Date from the submission and sets the
PTE Comments to System generated value. Processing continues at #2.
N/A
1B
Set the PTE Date to the Permit Issue Date and set the PTE Comments to System generated value.
ICIS has determined a Permit Issued Permit Tracking Event exists in ICIS. ICIS sets the Permit Tracking
Event Date to the Permit Issue Date and sets the Permit Tracking Event Comments to System generated
value. Processing continues at #1C.
N/A
1C
Does a previous version of the Permit exist?
ICIS has just finished setting the PTE Date and PTE Comments for the Permit Issued Permit Tracking
Event. If a previous version of the Permit exists, processing continues at #2; otherwise processing
continues at #1D.
N/A
1D
Set the Original Permit Issue Date to the Permit Issue Date.
ICIS has determined that a previous version of the Permit does not exist. ICIS sets the Original Permit
Issue Date to the Permit Issue Date submitted in the batch. Processing continues at #4.
N/A
2
Is Permit Effective Date entered?
ICIS determines if the Permit Effective Date was entered in the transaction. If the Permit Effective Date
was entered, processing continues at #2A; otherwise processing continues at #3.
N/A
28
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
2A
Enter the Permit Effective Permit Tracking Event in the Permit Tracking Events List.
ICIS has determined the Permit Effective Date was entered in the transaction. ICIS enters the Permit
Effective Permit Tracking Event in the Permit Tracking Events List. Processing continues at #2B.
N/A
2B
Set the PTE Date to the Permit Effective Date and set the PTE Comments to System generated
value.
ICIS sets the Permit Tracking Event Date to the Permit Effective Date and sets the Permit Tracking Event
Comments to System generated value. Processing continues at #3.
N/A
3
Is Permit Expiration Date entered?
ICIS determines if the Permit Expiration Date was entered in the transaction. If the Permit Expiration Date
was submitted in the transaction, processing continues at #3A; otherwise processing continues at #4.
N/A
3A
Enter the Permit Expiration Permit Tracking Event in the Permit Tracking Events List.
ICIS has determined the Permit Expiration Date was submitted in the transaction. ICIS enters the Permit
Expiration Permit Tracking Event in the Permit Tracking Events List. Processing continues at #3B.
N/A
3B
Set the PTE Date to the Permit Expiration Date and set the PTE Comments to System generated
value.
ICIS sets the Permit Tracking Event Date to the Permit Expiration Date and sets the Permit Tracking Event
Comments to System generated value. Processing continues at #4.
N/A
4
Does a Permit Continued Tracking Event exist for the Permit?
ICIS determines if a Permit Continued Tracking Event exists for the Permit in ICIS. If a Permit Continued
Tracking Event exists for the Permit, processing continues at #5; otherwise processing continues at #4A.
N/A
4A
Does Permit Status equal Administratively Continued?
ICIS has determined that a Permit Continued Tracking Event does not exist for the Permit. If Permit Status
equals Administratively Continued, processing continues at #4B; otherwise processing continues at #5.
N/A
4B
Enter the Permit Continued Permit Tracking Event in the Permit Tracking Events list.
ICIS has determined that Permit Status equals Administratively Continued. ICIS enters the Permit
Continued Permit Tracking Event in the Permit Tracking Events List. Processing continues at #4C.
N/A
4C
Set the PTE Date to the Permit Expiration Date + 1 day and set the PTE Comments to System
generated value.
ICIS sets the Permit Tracking Event Date to the Permit Expiration Date plus one day and sets the Permit
Tracking Event Comments to System generated value. Processing continues at #5.
N/A
5
Return to calling program.
ICIS returns to the calling program (Table 2-10: New Master General Permit Processing (#6), Table 2-16:
Change Master General Permit Processing (#8), or Table 2-20: Replace Master General Permit
Processing (#6)).
N/A
29
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.3.4 New Master General Permit Sample Scenarios
A New Master General Permit XML transaction should contain a valid NPDES ID that does not
already exist in ICIS. Examples of New Master General Permit scenarios are described below.
Example 1
If the submitted New Master General Permit XML includes:
•
•
•
•
•
Permit key that does not already exist in ICIS
Required data
No invalid data
An Effective Date that is less than the current date
An Expiration Date that is greater than the current date
ICIS will accept the transaction, add the Permit to the ICIS database, and save the required and
optional fields. ICIS will generate a Permit Status of Effective. Table 2-13: New Master General
Permit Example 1 provides an example.
Table 2-13: New Master General Permit Example 1
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID: VA0000004
NPDES ID: VA0000004
Type: NPDES MGP
Type: NPDES MGP
Valid required data
Valid required data
Effective Date = 01/01/2008
Effective Date = 01/01/2008
Expiration Date = 12/31/2012
Expiration Date = 12/31/2012
Permit Status: Effective
Other system generated fields
Non-Government Contact
Non-Government Contact
Example 2
If the submitted New Master General Permit XML includes:
•
•
Permit key that exists in ICIS
Required data
ICIS will reject the New Master General Permit transaction because the Permit already exists in
ICIS. Table 2-14: New Master General Permit Example 2 provides an example.
30
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-14: New Master General Permit Example 2
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000002
NPDES ID VA0000002
NPDES ID VA0000002
Type: NPDES MGP
Type: NPDES MGP
Type: NPDES MGP
Valid required data
Other valid required data
Valid required data
Non-Government Contact
Example 3
If the submitted New Master General Permit XML includes:
•
•
Permit key that does not already exist in ICIS
Some, but not all required data (missing General Permit Category)
ICIS will reject the New Master General Permit transaction because all required data are not
submitted. Table 2-15: New Master General Permit Example 3 provides an example.
Table 2-15: New Master General Permit Example 3
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000003
Type: NPDES MGP
Some, but not all required data
2.4 CHANGE (C) MASTER GENERAL PERMIT PROCESSING
The Change Master General Permit XML transaction allows the user to submit specific changes
to data for a Master General Permit. For the Permit identified in the transaction, ICIS updates
only the fields specified in the XML.
The processing of a Change Master General Permit XML transaction in ICIS is described below.
Also included in this section are sample Change Master General Permit scenarios.
2.4.1 Change Master General Permit Processing Flow
Figure 2-6: Change Master General Permit Processing Flow is a diagram depicting the
processing of a Change Master General Permit XML transaction. It references several of the
diagrams included in Section 2.3 New (N) Master General Permit Processing. Those diagrams
are Generate Permit Status (Figure 2-4) and Process Permit Tracking Event Data (Figure 2-5). A
table detailing each step in the flow diagram is also included in this section.
31
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Figure 2-6: Change Master General Permit Processing Flow
32
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-16: Change Master General Permit Processing contains a description of the items in the above Change Master General Permit
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. Business Rules relating to Contacts and Addresses, denoted with CA, can be found in Attachment A:
ICIS Batch Contacts and Addresses. All other business rules relating to Master General Permits can be found in Table 2-25: Batch
Master General Permit Business Rules.
Table 2-16: Change Master General Permit Processing
Item
Number
Item Description
Mapping To Business Rule Table
1
Does the Permit exist in ICIS?
ICIS determines if a Permit exists in ICIS that matches the key data submitted. The XML key tag for a
Permit is PermitIdentifier. If a matching Permit is found in ICIS, processing continues at #2; otherwise
processing continues at #1A.
ID 6
1A
Reject transaction. Write 1 error message to the error log.
If the XML key tag for the Permit cannot be found in ICIS, then the transaction is rejected. An error
message is written to the error log, and processing of this Change Master General Permit XML transaction
ends.
ID 6
2
Does user have privileges to perform Change Master General Permit XML transaction?
ICIS determines if the user has the privileges to perform a Change Master General Permit transaction and
if the user has the authority to conduct a Change Master General Permit transaction for the state/region
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 Edit Master General Permit function, which is available as part of the
Master General Permit Editor role. If the ICIS User ID has the correct privileges, processing continues at
#3; otherwise processing continues at #2A.
ID 2
2A
Reject transaction. Write 1 error message to the error log.
If the ICIS User ID does not have the correct privileges defined in ICIS for this Change Master General
Permit transaction, then ICIS rejects the entire Change Master General Permit XML transaction. ICIS
writes an error message to the error log, and processing of this Change Master General Permit XML
transaction ends.
ID 2
3
Does the submission contain data other than key data?
ICIS determines whether any data besides the key data have been submitted for the Change Master
General Permit transaction. If any data besides the key data has been submitted, processing continues at
#4; otherwise processing continues at #3A.
ID 3
33
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
3A
Reject transaction. Write 1 error message to the error log.
If no data besides the key data have been submitted in this Change Master General Permit XML
transaction, ICIS rejects the entire Change Master General Permit XML transaction because changes were
submitted with the Change Master General Permit transaction. ICIS writes an error message to the error
log, and processing of this Change Master General Permit XML transaction ends.
ID 3
4
Generate Permit Status (Figure 2-4).
ICIS continues processing the data for the Change Master General Permit XML transaction under Table
2-11: Generate Permit Status and then processing continues at #5.
N/A
5
Overlay changed field (s).
ICIS overlays the fields from the Change Master General Permit XML transaction over the current fields in
ICIS so that it can evaluate the entire record for validity. Processing continues at #6.
N/A
6
Are the data valid?
ICIS determines if all required data are submitted and checks validity of all required and optional data. If
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.
IDs 7-37, CA IDs 1-9
6A
Reject transaction. Write 1 error message per business rule violation to the error log.
If ICIS determines that required and/or optional data are incomplete and/or invalid, ICIS rejects the entire
Change Master General Permit XML transaction. ICIS writes an error message to the error log, and
processing of this Change Master General Permit XML transaction ends.
IDs 7-37, CA IDs 1-9
7
Process Permit Tracking Event Data (Figure 2-5).
ICIS has determined that the data are valid for this Change Master General Permit XML transaction. ICIS
continues processing at Table 2-12: Process Permit Tracking Event Data and then processing continues
at #8.
N/A
8
Save the Permit to the database.
ICIS has just completed processing permit data from Table 2-12: Process Permit Tracking Event Data.
ICIS saves the overlaid changed fields. Processing of this Change Master General Permit XML transaction
continues at #9.
N/A
9
Accept Transaction.
ICIS logs an accepted Change Basic Permit or General Permit transaction. Processing of this Change
Master General Permit XML transaction is complete.
N/A
34
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.4.2 Change Master General Permit Sample Scenarios
A Change Master General Permit transaction can contain many different combinations of data. It
may contain all of the fields that are expected for a Master General Permit or only some of the
fields. A few of these submission variations with the associated system results are described
below.
Example 1
If the submitted Master General Permit XML includes:
•
•
Updated data for specific fields
No invalid data
ICIS will update the specific data fields entered for that permit with the data submitted in the
Change Master General Permit XML transaction. The other data fields for that permit will
remain unchanged. Table 2-17: Change Master General Permit Example 1 provides an example.
Table 2-17: Change Master General Permit Example 1
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000003
Permit Issuing Organization Type:
State
Permit Issuing Organization Type:
State
Permit Status: Effective
Permit Status: Effective
Associated Permits: VA0000010,
VA0000011, VA0000012
Associated Permits: VA0000010,
VA0000011, VA0000012
Permit SIC Codes: 8041, 8734, 9511 Permit SIC Code: *
Permit SIC Primary Indicator: *
No SIC Codes saved for this permit.
Permit NAICS Codes: 237110,
221320
Permit NAICS Code: *
No NAICS Codes saved for this
Permit NAICS Primary Indicator Code: permit.
*
Example 2
If the submitted Master General Permit XML includes:
•
•
Updated data for specific fields
Associated Permit that does not exist in ICIS
ICIS will reject the transaction because the submitted Associated Permit has a NPDES ID that
does not exist in ICIS. Table 2-18: Change Master General Permit Example 2 provides an
example.
35
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-18: Change Master General Permit Example 2
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB after Processing
NPDES ID VA0000003
Type: NPDES MGP
Type: NPDES MGP
Address: 1200 North Lacrosse Street Address: 3000 International Blvd
Address: 1200 North Lacrosse Street
Associated Permit: VANOEXIST
Example 3
If the submitted Master General Permit XML includes:
•
•
•
Updated data for specific fields
Effective Date that is in the past
No invalid data
ICIS will update the specific data fields entered for that facility with the data submitted in the
Change Master General Permit XML transaction. The other data fields for that permit will
remain unchanged. Table 2-19: Change Master General Permit Example 3 provides an example.
Table 2-19: Change Master General Permit Example 3
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID SD0000003
Permit Issuing Organization Type:
Local
Permit Issuing Organization Type:
State
Permit Issuing Organization Type:
State
Permit Issue Date: 08/01/2009
Permit Issue Date: 08/01/2009
Permit Effective Date: 08/01/2009
Permit Effective Date: 08/01/2009
Permit Expiration Date:12/31/2013
Permit Expiration Date:12/31/2013
Permit Status: Pending
Permit Status: Effective
2.5 REPLACE (R) MASTER GENERAL PERMIT PROCESSING
The Replace Master General Permit transactions allow the user to submit Permit data to ICIS
without considering the current state of the data in ICIS. In processing the transaction, ICIS will
determine whether or not the Permit already exists. If the Permit does not exist in ICIS, the
Replace transaction behaves similarly to a New transaction and creates a new Permit. In this
case, most of the New business rules apply to the Replace transaction. If the Permit already
exists in ICIS, the Replace transaction behaves similarly to a Change transaction and updates the
existing record in ICIS with the data provided, blanking out fields that were not submitted. In
this case, most of the Change business rules apply to the Replace transaction.
In a Replace transaction, ICIS will replace the data for the Permit with the data submitted in the
XML, and will blank out data for any tags that were not submitted in the XML. It is important to
note that there are some Permit fields (or groups of fields) that cannot be submitted through
batch transactions, either because they are web-only fields or because they are system-generated;
36
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
these fields are not available for entry in the Master General Permit schema. In a Replace
transaction where the Permit already exists in ICIS, the system will not blank out these fields:
•
•
•
•
•
•
•
•
•
•
Government Contacts
Activity ID
Version Number
Original Issue Date
Retirement Date
Termination Date
Lifecycle Status Code
Creation Type Code
TMDL Interface Flag
EDMR Authorization Flag
The processing of a Replace Master General Permit XML transaction in ICIS is described below.
Also included in this section are sample Replace Master General Permit scenarios.
2.5.1 Replace Master General Permit Processing Flow
Figure 2-7: Replace Master General Processing Flow is a diagram depicting the processing of a
Replace Master General Permit transaction. It references several of the diagrams included in
Section 2.3 New (N) Master General Permit Processing. A table detailing each step in the flow
diagram is also included in this section.
37
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Figure 2-7: Replace Master General Permit Processing Flow
38
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Table 2-20: Replace Master General Permit Processing contains a description of the items in the above Replace Master General Permit
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. Business Rules relating to Contacts and Addresses, denoted with CA, can be found in Attachment A:
ICIS Batch Contacts and Addresses. All other business rules relating to Master General Permits can be found in Table 2-25: Batch
Master General Permit Business Rules.
Table 2-20: Replace Master General Permit Processing
Item
Number
Item Description
Mapping To Business Rule Table
1
Does user have privileges to perform Replace Master General Permit XML transaction?
ICIS determines if the user has the privileges to perform a Replace Master General Permit transaction and
if the user has the authority to conduct a Replace Master General Permit transaction for the state/region
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 Master General Permit and Edit Master General Permit
functions, which are available as part of the Master General Permit Editor role for all Replace transactions.
If the ICIS User ID has the correct privileges, processing continues at #2; otherwise processing continues
at #1A.
ID 2
1A
Reject transaction. Write 1 error message to the error log.
If the ICIS User ID does not have the correct privileges defined in ICIS for this Replace Master General
Permit transaction, then ICIS rejects the entire Replace Master General Permit XML transaction. ICIS
writes an error message to the error log, and processing of this Replace Master General Permit XML
transaction ends.
ID 2
2
Generate Permit Status (Figure 2-4).
ICIS continues processing the data for the Replace Master General Permit XML transaction under Table
2-11: Generate Permit Status and then processing continues at #3.
N/A
3
Does the Permit exist in ICIS?
ICIS determines if a Permit exists in ICIS that matches the key data submitted. The XML key tag for a
Permit is PermitIdentifier. If a matching Permit is found in ICIS, processing continues at #4; otherwise
processing continues at #3A.
N/A
3A
Are the data valid?
ICIS has determined that the Permit does not already exist. ICIS determines if all required data are
submitted and checks validity of all required and optional data. If required data are submitted and required
and optional data are valid according to the business rules, processing continues at #5; otherwise
processing continues at #3A1.
IDs 5, 7, 9-14, 20-35, 38, CA IDs 1-9
39
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Item
Number
Item Description
Mapping To Business Rule Table
3A1
Reject transaction. Write 1 error message per business rule violation to the error log.
If ICIS determines that required and/or optional data are incomplete and/or invalid, ICIS rejects the entire
Replace Master General Permit XML transaction. ICIS writes 1 error message per business rule violated to
the error log, and processing of this Replace Master General Permit XML transaction ends.
IDs 5, 7, 9-14, 20-35, 38, CA IDs 1-9
4
Are the data valid?
ICIS has determined that the Permit already exists. ICIS determines if all required data are submitted and
checks validity of all required and optional data. If required data are submitted and required and optional
data are valid according to the business rules, processing continues at #5; otherwise processing continues
at #4A.
IDs 7-37, CA IDs 1-9
4A
Reject transaction. Write 1 error message per business rule violation to the error log.
If ICIS determines that required and/or optional data are incomplete and/or invalid, ICIS rejects the entire
Replace Master General Permit XML transaction. ICIS writes 1 error message per business rule violated to
the error log, and processing of this Replace Master General Permit XML transaction ends.
IDs 7-37, CA IDs 1-9
5
Process Permit Tracking Event Data (Figure 2-5).
ICIS has determined that the data are valid for this Replace Master General Permit XML transaction.
Processing continues at Table 2-12: Process Permit Tracking Event Data and then continues at #6.
N/A
6
Save the Permit to the database.
ICIS has completed processing data from Table 2-12: Process Permit Tracking Event Data. ICIS saves the
overlaid changed fields. It sets the Version Number for the Master General Permit to 0 for the Replace (like
New) transaction. Processing of this Replace Master General Permit XML transaction continues at #7.
N/A
7
Accept Transaction.
ICIS logs an accepted Replace Master General Permit transaction. Processing of this Replace Master
General Permit XML transaction is complete.
N/A
40
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.5.2 Replace Master General Permit Sample Scenarios
A Replace Master General Permit transaction allows the user to submit data for a permit
regardless of whether the permit already exists in ICIS. Examples of possible Replace Master
General Permit scenarios are described below.
Example 1
If the submitted Replace Master General Permit XML includes:
•
•
NPDES ID that already exists in ICIS
No invalid data
ICIS will accept the transaction and save the submitted data to the database. Table 2-21: Replace
Master General Permit Example 1 provides an example.
Table 2-21: Replace Master General Permit Example 1
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000002
NPDES ID VA0000002
NPDES ID VA0000002
Permit Type: NPDES MGP
Permit Type: NPDES MGP
Permit Type: NPDES MGP
Issuing Organization Type: State
Issuing Organization Type: State
Issuing Organization Type: State
First Name: John
First Name: Jon
First Name: Jon
Last Name: Smith
Last Name: Smith
Last Name: Smith
Contact Start Date: 08/27/2009
Contact Start Date: 08/27/2009
Individual Title: Manager
Contact Start Date: 08/27/2009
Example 2
If the submitted Replace Master General Permit XML includes:
•
•
NPDES ID that does not exist in ICIS
No invalid data
ICIS will accept the transaction and save the Master General Permit to the database. Table 2-22:
Replace Master General Permit Example 2 provides an example.
Table 2-22: Replace Master General Permit Example 2
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000003
NPDES ID VA0000003
Permit Type: NPDES MGP
Permit Type: NPDES MGP
Issuing Organization Type: State
Issuing Organization Type: State
First Name: John
First Name: John
Last Name: Smith
Last Name: Smith
Individual Title: Manager
Individual Title: Manager
Contact Start Date: 08/27/2009
Contact Start Date: 08/27/2009
41
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
Example 3
If the submitted Master General Permit XML includes:
•
•
•
NPDES ID that already exists in ICIS
SIC/NAICS codes (multi-value items)
No invalid data
ICIS will accept the transaction and save the Master General Permit to the database. Table 2-23:
Replace Master General Permit Example 3 provides an example.
Table 2-23: Replace Master General Permit Example 3
MGP Data in ICIS DB
MGP XML Submission
Result in ICIS DB After Processing
NPDES ID VA0000003
NPDES ID VA0000003
NPDES ID VA0000003
Permit Issuing Organization Type:
State
Permit Issuing Organization Type:
State
Permit Issuing Organization Type:
State
Permit SIC Codes: 8041, 8734, 9511 Permit SIC Codes: 8041
Permit SIC Codes: 8041
Permit NAICS Codes: 237110,
221320
Permit NAICS Codes: 221320
Permit NAICS Codes: 221320
Example 4
If the submitted Replace Master General Permit XML includes:
•
•
NPDES ID that already exists in ICIS
Invalid data (Permit Issuing Organization Type missing)
ICIS will reject the transaction because Permit Issuing Organization Type must exist in ICIS.
Table 2-24: Replace Master General Permit Example 4 provides an example.
Table 2-24: Replace Master General Permit Example 4
MGP Data in ICIS DB
NPDES ID: VA0020305
MGP XML Submission
NPDES ID: VA0020305
Permit Issuing Organization Type:
State
Permit Issuing Organization Name:
State Environmental Organization
Result in ICIS DB After Processing
NPDES ID: VA0020305
Permit Issuing Organization Type:
State
Permit Issuing Organization Name:
EPA Contractor
Permit Issuing Organization Name:
State Environmental Organization
42
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
2.6 BUSINESS RULES
Table 2-25: Batch Master General Permit Business Rules lists the business rules that apply to batch Master General Permit
transactions. Each row has a unique ID which identifies the business rule. The Business Rules column describes the specific business
rule that is being applied to the Master General Permit transactions. These rules are the same business rules (unless otherwise
indicated as new for Batch functionality) that are currently implemented in the production system. The naming of the data fields is
therefore consistent with the existing production system terminology and not the batch XML schema terminology. The two Where
Enforced columns identify the code tier that is responsible for enforcing the business rule. The Rejection Tolerance column identifies
the level of rejection that violating the business rule causes. The next three columns, Error/Warning Code, Transaction Keys, and
Error/Warning Message identify the code for error/warning messages, the keys that identify the specific record, and 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 keys that will be displayed for Master General Permit transactions are listed below in the
Transaction Keys column. The last column, Applicable Transaction Types, describes to which transaction types this particular rule
applies.
Table 2-25: Batch Master General Permit Business Rules
ID
Business Rules
Where
Enforced
(Web)
1
Transaction Type must be valid for
N/A
Permits. Valid Transaction Types are D
(Delete), N (New), C (Change), and R
(Replace).
2
User must have privileges to perform
the transaction. This relates to specific
roles and access level (HQ, specific
region, specific state).
Note: ICIS does not have Batchspecific privileges. The privileges for
Batch and Web access are the same.
3
If the permit contains key data and no N/A
other data, ICIS rejects the Permit
transaction.
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
Business
rule layer
(new)
Reject entire
BAT010
Master General
Permit
transaction
Permit Identifier
Transaction Type <Transaction
Type value> is not valid for
<Submission Type value>.
N, C, R, D
Graphical Business
User
rule layer
Interface (new)
(GUI)
Reject entire
BAT020
Master General
Permit
transaction
Permit Identifier
User <ID value> does not have
privileges to perform this
<Transaction Type value>
<Submission Type value>
transaction.
N, C, R, D
Reject entire
MGP030
Master General
Permit
transaction
Permit Identifier
The Permit transaction contains
key data and no other data for
processing.
C
Business
rule layer
(new)
Permit Key Element(s)
43
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
4
The permit identified by the NPDES ID Business Business
rule layer rule layer
must not already exist in the ICIS
system.
Reject entire
MGP040
Master General
Permit
transaction
Permit Identifier
A permit already exists for the key N
data entered.
5
NPDES ID must follow the following
Business Business
format:
rule layer rule layer
• Positions 1 and 2 must be a valid
State or Tribe (i.e., in the
REF_STATE table, usage
indicator is N or B) or a Valid
Region (i.e., 01-10).
• Positions 3–9 must be
alphanumeric and must be a
unique combination within a
common value for positions 1–2
(i.e., must be unique within state,
tribe, or region except for multiple
versions of the same Permit).
Note: This business rule is not checked
for Replace transactions where the
Permit exists in ICIS.
Reject entire
MGP050
Master General
Permit
transaction
Permit Identifier
Permit Identifier <Permit Identifier N, R
value> is not a valid format.
6
NPDES ID submitted must exist in
ICIS.
Business Business
rule layer rule layer
Reject entire
MGP060
Master General
Permit
transaction
Permit Identifier
A permit does not exist for the key C, D
data entered.
39 The Permit cannot be deleted if it has Business Business
any GPCFs linked to it.
rule layer rule layer
(new)
Note: This business rule is not checked
for Permits where a previous version of
the Permit exists.
Reject entire
MGP380
Master General
Permit
transaction
Permit Identifier.
The Permit cannot be deleted
D
because at least one linked GPCF
exists.
Permit Deletion
44
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
40 A Permit cannot be deleted if it is the Business Business
rule layer rule layer
only version of the Permit and it is
(new)
listed as an Associated NPDES Permit
for (the current version of) at least one
other Permit.
Note: This business rule is not checked
for Permits where a previous version of
the Permit exists.
Reject entire
MGP390
Master General
Permit
transaction
Permit Identifier
The Permit cannot be deleted
because it is the only version of
the Permit and it is listed as an
Associated NPDES Permit for at
least one other Permit.
D
41 If the Permit Status = Terminated, the Business Business
Permit cannot be deleted.
rule layer rule layer
(new)
Reject entire
MGP400
Master General
Permit
transaction
Permit Identifier
The Permit cannot be deleted
because the Permit Status =
Terminated.
D
Permit Type
38 Permit Type must exist for a Permit in GUI
ICIS.
Note: This business rule is not checked
for Replace transactions where the
Permit exists in ICIS.
Business
rule layer
(new)
Reject entire
permit
transaction
MGP065
Permit Identifier
Permit Type Code must be
entered for a permit.
N, R
7
When submitting the Master General N/A
Permit Data Payload, the Permit Type
must be one of the following:
• NPDES Master General Permit
• State Issued Master General
Permit (Non- NPDES)
Business
rule layer
(new)
Reject entire
MGP070
Master General
Permit
transaction
Permit Identifier
The Permit Type Code <Permit
Type Code value> is invalid for
the Master General Permit Data
Payload.
N, C, R, D
8
Permit Type cannot be changed.
GUI
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Business
rule layer
(new)
Reject entire
MGP080
Master General
Permit
transaction
Permit Identifier
Permit Type Code cannot be
changed.
C, R
Web Tier Business
rule layer
(new)
Reject entire
MGP100
Master General
Permit
transaction
Permit Identifier
Agency Type Code must be
entered for a permit.
N, C, R
Permit Agency Type
9
Agency Type must be entered for a
Master General Permit.
45
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
10 Agency Type must be a valid (i.e.,
Active) code with an
Activity_Group_Code = PER in the
REF_AGENCY_TYPE table.
Where
Enforced
(Web)
Where
Enforced
(Batch)
Web Tier Business
rule layer
(new)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
Reject entire
MGP110
Master General
Permit
transaction
Permit Identifier
Agency Type Code <Agency Type N, C, R
Code value> is not valid for
permits, or is inactive in the ICIS
reference table.
Reject entire
permit
transaction
MGP115
Permit Identifier
Permit Status Code cannot be
changed because the current
status is Terminated.
11 If any one of the Permit Dates (Issue, Business Business
Effective, or Expiration) exists, then all rule layer rule layer
3 dates must exist.
Reject entire
MGP120
Master General
Permit
transaction
Permit Identifier
When any one of the Permit Dates N, C, R
(Permit Issue Date, Permit
Effective Date, and Permit
Expiration Date) exists, all three
Permit Dates must exist. One or
more of the dates are missing.
12 Permit Issue Date must be less than or Business Business
equal to Permit Effective Date.
rule layer rule layer
Reject entire
MGP130
Master General
Permit
transaction
Permit Identifier
The Permit Issue Date <Permit
Issue Date value> must be less
than or equal to Permit Effective
Date <Permit Effective Date
value>.
13 Permit Effective Date must be less
than or equal to Permit Expiration
Date.
Business Business
rule layer rule layer
Reject entire
MGP140
Master General
Permit
transaction
Permit Identifier
The Permit Effective Date <Permit N, C, R
Effective Date value> must be
less than or equal to Permit
Expiration Date <Permit Expiration
Date value>.
14 Permit Expiration Date cannot be
Business Business
greater than 5 years after the Permit rule layer rule layer
Effective Date.
Note: This rule is only checked if
Permit Effective Date and Permit
Expiration Date have not already been
saved.
Reject entire
MGP150
Master General
Permit
transaction
Permit Identifier
The Permit Expiration Date
<Permit Expiration Date value>
cannot be greater than 5 years
after the Permit Effective Date
<Permit Effective Date value>.
Permit Status
37 If the Permit Status Code is
Business Business
Terminated, it cannot be changed.
rule layer rule layer
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
C, R
Permit Dates
N, C, R
N, C, R
46
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
15 If a Limit Set exists when the Permit
Business Business
rule layer rule layer
dates are entered, the earliest
Monitoring Period End Date /
Modification Monitoring Period End
Date must be greater than the Permit
Effective Date.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Reject entire
MGP160
Master General
Permit
transaction
Permit Identifier
Error/Warning Message
Applicable
Transaction
Types
The earliest Monitoring Period
C, R
End Date for Limit Set(s) <
Permitted Feature Identifier value
1| Limit Set Designator value 1,
Permitted Feature Identifier value
2| Limit Set Designator value 2,…
Permitted Feature Identifier value
n| Limit Set Designator value n>
must be greater than the Permit
Effective Date <Permit Effective
Date value>.
Note: For this error message,
each Limit Set will be listed that
has this error.
16 If a Limit Set exists, the Limit Set
Business Business
Schedule Modification Effective Date rule layer rule layer
must be greater than or equal to the
Permit Issue Date.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Reject entire
MGP170
Master General
Permit
transaction
Permit Identifier
The Modification Effective Date of C, R
Limit Set(s) < Permitted Feature
Identifier value 1| Limit Set
Designator value 1, Permitted
Feature Identifier value 2| Limit
Set Designator value 2,…
Permitted Feature Identifier value
n| Limit Set Designator value n>
must be greater than or equal to
the Permit Issue Date <Permit
Issue Date value>.
Note:
For this error message, each Limit
Set will be listed that has this
error.
47
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
17 If a Limit Set exists when the Permit
Business Business
rule layer rule layer
Dates are entered, the Limit Set
Schedule Modification Effective Date
must be less than or equal to the
Permit Expiration Date.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Reject entire
MGP180
Master General
Permit
transaction
Permit Identifier
The Modification Effective Date of C, R
Limit Set(s) < Permitted Feature
Identifier value 1| Limit Set
Designator value 1, Permitted
Feature Identifier value 2| Limit
Set Designator value 2,…
Permitted Feature Identifier value
n| Limit Set Designator value n>
must be less than or equal to the
Permit Expiration Date <Permit
Expiration Date value>.
Note:
For this error message, each Limit
Set will be listed that has this
error.
18 If a Permit Schedule exists when the Business Business
rule layer rule layer
Permit Dates are entered, the
Schedule Date of the earliest Permit
Schedule Event must be greater than
or equal to the Permit Effective date.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Reject entire
permit
transaction
MGP190
Permit Identifier
The earliest Schedule Date of the C, R
Permit Schedule(s) < Narrative
Condition Number value 1,
Narrative Condition Number value
2,…Narrative Condition Number
value n> must be greater than or
equal to the Permit Effective Date
<Permit Effective Date value>.
Note:
For this error message, each
Permit Schedule will be listed that
has this error.
19 Permit Effective Date and Permit
GUI
Expiration Date cannot be changed
once they have been saved.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Reject entire
permit
transaction
MGP200
Permit Identifier
Permit Effective Date and Permit C, R
Expiration Date cannot be
changed.
Business
rule layer
(new)
48
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
Associated Permits
20 The value entered in Associated
NPDES ID must exist in ICIS.
Business Business
rule layer rule layer
Reject entire
MGP210
Master General
Permit
transaction
Permit Identifier
Associated Permit <Associated
N, C, R
Permit Identifier value 1,
Associated Permit Identifier 2,
…Associated Permit Identifier n>
does not exist in ICIS.
21 The combination of Associated NPDES Business Business
rule layer rule layer
ID and Association Reason must be
unique within the permit.
Reject entire
MGP220
Master General
Permit
transaction
Permit Identifier
The combination of Associated
N, C, R
Permit Identifier <Associated
Permit Identifier value> and
Associated Permit Reason Code
<Associated Permit Reason Code
value> already exists for this
permit.
22 Association Reason Code must be a
valid (i.e., Active) code in the
REF_PERM_ASSOCIATION table.
Reject entire
MGP230
Master General
Permit
transaction
Permit Identifier
Associated Permit Reason Code N, C, R
<Associated Permit Reason Code
value 1, Associated Permit
Reason Code value
2,…Associated Permit Reason
Code n> does not exist or is
inactive in the ICIS reference
table.
Business
rule layer
(new)
Reject entire
MGP240
Master General
Permit
transaction
Permit Identifier
Both asterisks and values were
N, C, R
entered in the required tags
Associated Permit Identifier and
Associated Permit Reason Code.
All asterisks or all values must be
entered in the required tags.
24 Permit SIC Code must be a valid (i.e., Web Tier Business
Active) code in the REF_SIC table.
rule layer
(new)
Reject entire
MGP250
Master General
Permit
transaction
Permit Identifier
Permit SIC Code <SIC Code
N, C, R
value 1, SIC Code value 2,…SIC
Code value n> does not exist or is
inactive in the ICIS reference
table.
Web Tier Business
rule layer
(new)
23 Asterisks must be entered in all
N/A
required Associated Permit tags
(Associated Permit Identifier and
Associated Permit Reason Code) to
blank out all Associated Permits. If
asterisks are only entered in some
required tags and values are entered in
other required tags, the transaction will
be rejected.
Permit SIC and NAICS Codes
49
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
25 Only one permit SIC Code can be
designated as the Primary SIC Code.
GUI
Business
rule layer
(new)
Reject entire
MGP260
Master General
Permit
transaction
Permit Identifier
More than one permit SIC Code
<SIC Code value 1, SIC Code
value 2, … SIC Code value n>
has been designated with a SIC
Primary Indicator Code.
26 Permit NAICS Code must be a valid
(i.e., Active) code in the REF_NAICS
table.
Web Tier Business
rule layer
(new)
Reject entire
MGP270
Master General
Permit
transaction
Permit Identifier
Permit NAICS Code <NAICS
N, C, R
Code value 1, NAICS Code Value
2,… NAICS Code value n> does
not exist or is inactive in the ICIS
reference table.
27 Only one permit NAICS Code can be
designated as the Primary NAICS
Code.
GUI
Business
rule layer
(new)
Reject entire
MGP280
Master General
Permit
transaction
Permit Identifier
More than one permit NAICS
N, C, R
Code <NAICS Code value 1,
NAICS Code value 2, … NAICS
Code value n> has been
designated with a NAICS Primary
Indicator Code.
28 Asterisks must be entered in all
N/A
required permit SIC tags (SIC Code
and Primary SIC) to blank out all
permit SIC Codes. If asterisks are only
entered in some required tags and
values are entered in other required
tags, the transaction will be rejected.
Business
rule layer
(new)
Reject entire
MGP290
Master General
Permit
transaction
Permit Identifier
Both asterisks and values were
entered in the required tags SIC
Code and SIC Primary Indicator
Code. All asterisks or all values
must be entered in the required
tags.
29 Asterisks must be entered in all
N/A
required permit NAICS tags (NAICS
Code and Primary NAICS) to blank out
all NAICS Codes. If asterisks are only
entered in some required tags and
values are entered in other required
tags, the transaction will be rejected.
Business
rule layer
(new)
Reject entire
MGP300
Master General
Permit
transaction
Permit Identifier
Both asterisks and values were
N, C, R
entered in the required permit tags
NAICS Code and NAICS Primary
Indicator Code. All asterisks or all
values must be entered in the
required tags.
30 The same permit SIC Code cannot be GUI
included multiple times with different
SIC Primary Indicator Codes.
Business
rule layer
(new)
Reject entire
permit
transaction
Permit Identifier
Permit SIC Code <SIC Code
value> was submitted multiple
times with different SIC Primary
Indicator Code values.
MGP310
N, C, R
N, C, R
N, C, R
50
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
31 The same permit NAICS Code cannot GUI
be included multiple times with
different NAICS Primary Indicator
Codes.
Where
Enforced
(Batch)
Business
rule layer
(new)
Rejection
Tolerance
Reject entire
permit
transaction
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
MGP320
Permit Identifier
Permit NAICS Code <NAICS
Code value> was submitted
multiple times with different
NAICS Primary Indicator Code
values.
N, C, R
32 General Permit Industrial Category
Web Tier Business
must exist for a Master General Permit.
rule layer
(new)
Reject entire
MGP330
Master General
Permit
transaction
Permit Identifier
General Permit Industrial
Category must be entered for a
Master General Permit.
N, C, R
33 General Permit Industrial Category
must be a valid (i.e., Active) code in
the REF_PERM_INDUSTRIAL_CAT
table.
Reject entire
MGP340
Master General
Permit
transaction
Permit Identifier
General Permit Industrial
N, C, R
Category <General Permit
Industrial Category value> does
not exist or is inactive in the ICIS
reference table.
General Permit Industrial Category
Web Tier Business
rule layer
(new)
Permit Component (Multi-value data treated as a Replace Transaction)
34 Permit Component Type Code must be Web Tier Business
a valid (i.e., Active) code in the
rule layer
REF_COMPONENT_TYPE table.
(new)
Reject entire
MGP350
Master General
Permit
transaction
Permit Identifier
Permit Component Type Code
N, C, R
<Permit Component Type Code
value 1, Permit Component Type
Code value 2,… Permit
Component Type Code value n>
does not exist or is inactive in the
ICIS reference table.
35 The Permit Component Storm Water
Medium/Large MS4s is not a valid
component for MGPs.
Business
rule layer
(new)
Reject entire
MGP360
Master General
Permit
transaction
Permit Identifier
A Permit Component Storm Water N, C, R
Medium/Large MS4s is not valid
for a Master General Permit.
36 A Permit Component cannot be
Business Business
rule layer rule layer
removed from an MGP if any of the
GPCFs linked to that MGP also have
that component.
Note: This business rule is not checked
for Replace transactions where the
Permit does not exist in ICIS.
Reject entire
MGP370
Master General
Permit
transaction
Permit Identifier
The Permit Component Type
C, R
Code <Permit Component Type
Code value 1, Permit Component
Type Code value 2,… Permit
Component Type Code value n>
cannot be removed from the
Master General Permit because
one or more linked GPCFs have
the component.
GUI
51
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
ID
Business Rules
Where
Enforced
(Web)
Where
Enforced
(Batch)
Rejection
Tolerance
Error/Warning Transaction Keys
Code
Error/Warning Message
Applicable
Transaction
Types
Permit Contact (See Attachment A for the list of general Contact Business Rules)
52
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
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-1:
Master General Permit Data Element Mapping. The table is organized according to the order in which tags are listed in the Master
General Permit schema.
Table 3-1: Master General Permit Data Element Mapping
PCS Acronym
XML Tag Name
XML Data Type
ICIS Screen Name
ICIS Database Name
Master General Permit Key Field
NPID, SLID
PermitIdentifier
icis: String9FixedTypeBase
NPDES ID
icis_permit.external_permit_nmbr
Permit Data Group
EPST
PermitTypeCode
icis: StringMin1Max3TypeBase N/A
icis_permit.permit_type_code
N/A
AgencyTypeCode
Icis: StringMin1Max3Type
Type
icis_permit.agency_type_code
PTAC
PermitIssueDate
icis: DateType
Issue Date
icis_permit.issue_date
PTAC
PermitEffectiveDate
icis: DateType
Effective Date
icis_permit.effective_date
PTAC
PermitExpirationDate
icis: DateType
Expiration Date
icis_permit.expiration_date
RPRI
ReissuancePriorityPermitIndi icis: String1FixedType
cator
Indicator
icis_permit.reissuance_priority
N/A
BacklogReasonText
Backlog Reason
icis_permit.backlog_reason
N/A
PermitIssuingOrganizationTy icis: StringMin1Max100Type
peName
Name
icis_permit.issuing_agency
N/A
OtherPermitIdentifier
Icis: StringMin1Max30Type
Other Permit Number
icis_other_permit.other_external_permit_nmbr
N/A
OtherOrganizationName
Icis: StringMin1Max80Type
Organization Name
icis_other_permit.organization_name
N/A
OtherPermitIdentifierContext Icis: StringMin1Max100Type
Name
Other Permit Context
icis_other_permit.identifier_context_desc
NPDES ID
icis_perm_association.related_external_permit_n
mbr
Association Reason
icis_perm_association.perm_association_code
icis: StringMin1Max2000Type
Other Permits
Associated Permit
N/A
AssociatedPermitIdentifier
Icis: String9FixedType
N/A
AssociatedPermitReasonCo Icis: StringMin1Max3Type
de
53
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
PCS Acronym
XML Tag Name
XML Data Type
ICIS Screen Name
ICIS Database Name
Permit Appealed Indicator
N/A
PermitAppealedIndicator
icis: YesNoIndicatorType
Appealed
icis_permit.appeal_flag
SIC2
SICCode
icis:SICType
SIC Codes
xref_activity_sic_code
N/A
SICPrimaryIndicatorCode
icis: YesNoIndicatorType
Primary SIC
xref_activity_sic.primary_flag
icis:NAICSType
NAICS Codes
xref_activity_naics_code
Primary NAICS
xref_activity_naics.primary_flag
SICCodeDetails
NAICSCodeDetails
N/A
NAICSCode
N/A
NAICSPrimaryIndicatorCode icis: YesNoIndicatorType
User Defined Fields
RDF6
PermitUserDefinedDataelem icis: StringMin1Max30Type
ent1Text
1
icis_permit.udf1
RDF7
PermitUserDefinedDataelem icis: StringMin1Max30Type
ent1Text
2
icis_permit.udf2
RDF8
PermitUserDefinedDataelem icis: StringMin1Max30Type
ent1Text
3
icis_permit.udf3
RDF9
PermitUserDefinedDataelem icis: StringMin1Max30Type
ent1Text
4
icis_permit.udf4
RDF0
PermitUserDefinedDataelem icis: StringMin1Max30Type
ent1Text
5
icis_permit.udf5
Permit Comments
N/A
PermitCommentsText
icis: StringMin1Max4000Type
icis_permit.comment_text
Permit Contact (See Attachment A for detailed list of all Contact tags)
N/A
Contact
N/A
Non-Government Contacts
N/A
Master General Permit Basic Info
N/A
GeneralPermitIndustrialCate icis: StringMin1Max3Type
gory
General Permit Industrial
Category
icis_permit.perm_industrial_cat_code
N/A
PermitName
Permit Name
icis_permit.permit_name
N/A
PermitComponentTypeCode icis: StringMin1Max3Type
Components
xref_perm_component_type.component_type_cod
e
icis: StringMin1Max120Type
54
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
4. XML SCHEMA
The following sections of the ICIS XML schema are related to the Master General Permit
Submission Type:
•
•
•
•
•
•
•
ICIS_Common.xsd
ICIS_Contact.xsd
ICIS_Header.xsd
ICIS_Key_Elements.xsd
ICIS_Master_General_Permit.xsd
ICIS_Permit.xsd
ICIS_SIC_NAICS.xsd
55
ICIS Batch – Master General Permit Technical Specification, Version 1.5
Office of Enforcement and Compliance Assurance
APPENDIX A: ACRONYMS
Table A-1: Acronym List
Acronym
Definition
CA
Contacts & Addresses
CDX
Central Data Exchange
DB
Database
DMR
Discharge Monitoring Report
EPA
Environmental Protection Agency
GPCF
General Permit Covered Facility
ICIS
Integrated Compliance Information System
NPDES
National Pollutant Discharge Elimination System
MGP
Master General Permit
PCS
Permit Compliance System
PTE
Permit Tracking Event
XML
Extensible Markup Language
56
ICIS Batch – Master General Permit Technical Specification, Version 1.5