Schedule Import Scenarios
When importing mid-import or reimporting, the new data can extend past the current sign-up period and the period will be extended as described below. If the data is shorter than the current sign-up period, the import will fail.
| Scenario Image | Description |
|---|---|
| Sign-Up period end date is extended. | |
| A bid exists. | |
|
|
First attempt at import. |
| Scenario | Impact On | Impact Details |
|---|---|---|
| Schedule Data | General: All errors are logged in the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
| Schedule Data | General: All errors are logged in the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
| Sign-Up Extension |
If the import will extend the sign-up period, a message is displayed. If the user does not click OK, the import is canceled and no data is changed. Bid period is extended. If the bid is extended, the last week of the original sign-up period is used to determine the rosters to use when duplicating work. If the original sign-up period ends in the middle of a biweekly roster (end with week 1), the first week of the extended period will be week 2. This maintains the biweekly roster structure. If extra work is part of a roster, the extra work is extended to the new end date of the sign-up period. That is, the To Date of the extra work is the end date of the extended sign-up period. If there is a holiday in the extension period, a holiday is generated for the roster. Volunteer status is extended based on the status of the last week of the original sign-up period. Non-rostered work is extended based on the last week. |
|
| No bid. No change to sign-up. Not the first import. | Schedule data | General: All errors are logged to the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
| Schedule Data | General: All errors are logged in the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
|
Bid Information |
Rosters are matched by name and division ID. If the roster exists, the new information replaces the old. If the roster does not exist, it is created. If there is no match for an existing roster, it is removed. This only affects imported rosters, manually created roster such as extraboard rosters are not affected. Runs are matched by name, division ID, and service group. The existing run version ID is used. When a new run is imported, it is created. If is selected, any changes between the two versions are presented in a dialog. If an operational bid references a roster that has been removed, the reference remains. |
|
| Sign-Up Extension |
If the import will extend the sign-up period, a message is displayed. If the user does not click OK, the import is canceled and no data is changed. Bid period is extended. If the bid is extended, the last week of the original sign-up period is used to determine the rosters to use when duplicating work. If the original sign-up period ends in the middle of a biweekly roster (end with week 1), the first week of the extended period will be week 2. This maintains the biweekly roster structure. If extra work is part of a roster, the extra work is extended to the new end date of the sign-up period. That is, the To Date of the extra work is the end date of the extended sign-up period. If there is a holiday in the extension period, a holiday is generated for the roster. Volunteer status is extended based on the status of the last week of the original sign-up period. Non-rostered work is extended based on the last week. |
|
|
Schedule Data |
General: All errors are logged in the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
|
Bid Information |
Rosters are matched by name and division ID. If the roster exists, the new information replaces the old. If the roster does not exist, it is created. If there is no match for an existing roster, it is removed. This only affects imported rosters; manually created roster such as extraboard rosters are not affected. Runs are matched by name, division ID, and service group. The existing run version ID is used. When a new run is imported, it is created. If is selected, any changes between the two versions are presented in a dialog. If an operational bid references a roster that has been removed, the reference remains. |
| Scenario | Impact On | Impact Details |
|---|---|---|
| No bid. No change to sign-up period. | Schedule Data |
General: All errors are logged to the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. (Error messages are displayed.) Check for run invalid line group. Invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
| Schedule Data | General: All errors are logged to the process log and the process continues. If a holiday exists without runs, the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. (Error messages are displayed. Check for run invalid line group. Invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
| Sign-Up Extension |
If the import will extend the sign-up period a message is displayed. If the user does not click OK, the import is canceled and no data is changed. Bid period is extended. If the bid is extended, the last week of the original sign-up period is used to determine the rosters to use when duplicating work. If the original sign-up period ends in the middle of a biweekly roster (end with week 1), the first week of the extended period will be week 2. This maintains the biweekly roster structure. If extra work is part of a roster, the extra work is extended to the new end date of the sign-up period. That is, the To Date of the extra work is the end date of the extended sign-up period. If there is a holiday in the extension period, a holiday is generated for the roster. Volunteer status is extended based on the status of the last week of the original sign-up period. Non-rostered work is extended based on the last week. |
|
| Schedule Data | General: All errors are logged to the process log and the process continues. If a holiday exists without runs the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. Error messages are displayed. Check for run invalid line group, invalid run type, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
| Bid Information |
The OPS version ID is incremented by one. The run version ID is incremented (ExcCombo +1+ maximum run version ID from the previous OPS version). This occurs each time you run the mid import process. The new roster holidays are used for bids. Rosters are matched by name and division ID. If the roster exists, the new information replaces the old. If the roster does not exist, it is created. If there is no match for an existing roster, it is removed. This only affects imported rosters; manually created rosters, such as extraboard rosters, are not affected. Runs are matched by name, division ID, and service group. When a new run is imported, it is created. If is selected, any changes between the two versions are presented in a dialog. This checks the week preceding the mid-term import and the first week of the import. If an operational bid references a roster that has been removed, the reference remains. |
|
| Schedule Data | General: All errors are logged to the process log and the process continues. If a holiday exists without runs the import continues but an error message is provided. If a BlockBuster run type contains multiple operators, the import will create a duplicate for each run of that run type. Check for invalid roster number, invalid roster type, duplicate roster numbers. (Error messages are displayed. Check for run invalid line group. Invalid runtype, invalid run number, and duplicate runs. Errors are logged on screen and in process log. Invalid runs are not imported, but the rest of division data is imported. |
|
| Bid Information |
The OPS version ID is incremented by one. The run version ID is incremented (exccombo +1+ maximum run version ID from the previous OPS version). This occurs each time you run the mid import process. The new roster holidays are used for bids. Rosters are matched by name and division ID. If the roster exists, the new information replaces the old. If the roster does not exist, it is created. If there is no match for an existing roster, it is removed. This only affects imported rosters, manually created roster such as extraboard rosters are not affected. Runs are matched by name, division ID, and service group. When a new run is imported, it is created. If is selected, any changes between the two versions are presented in a dialog. This checks the week preceding the mid-term import and the first week of the import. If an operational bid references a roster that has been removed, the reference remains. |
|
| Sign-Up Extension |
If the import will extend the sign-up period a message is displayed. If the user does not click OK, the import is canceled and no data is changed. Bid period is extended. If the bid is extended, the last week of the original sign-up period is used to determine the rosters to use when duplicating work. If the original sign-up period ends in the middle of a biweekly roster (end with week 1), the first week of the extended period will be week 2. This maintains the biweekly roster structure. If extra work is part of a roster, the extra work is extended to the new end date of the sign-up period. That is the To Date of the extra work is the end date of the extended sign-up period. If there is a holiday in the extension period, a holiday is generated for the roster. Volunteer status is extended based on the status of the last week of the original sign-up period. Non-rostered work is extended based on the last week. |
| Scenario | Impact On | Impact Details |
|---|---|---|
| There is no bid. The reimport being rolled back did not affect the sign-up period. | Schedule Data | The schedule data for the selected import (the import you are rolling back to) is used. The data should be the same as it was before the rolled back imports were performed. |
| There is no bid. The reimport being rolled back extended the sign-up period. | Schedule Data | The schedule data for the selected import (the import you are rolling back to) is used. The data should be the same as it was before the rolled back imports were performed. |
| Sign-Up | The data is extended to the end of the sign-up period as previously extended. This is identical to not having performed the rolled back import, but having extended the sign-up period. | |
| A bid exists. The reimport being rolled back did not affect the sign-up period. | Schedule Data | The schedule data for the selected import (the import you are rolling back to) is used. The data should be the same as it was before the rolled back imports were performed. |
| Bid Information | The bid information is returned to the state it was in for the selected import (the import you are rolling back to). It will have the OPS version ID of that import. | |
| A bid exists. The reimport being rolled backed extended the sign-up period. | Schedule Data | The schedule data for the selected import (the import you are rolling back to) is used. The data should be the same as it was before the rolled back imports were performed. |
| Bid Information | The bid information is returned to the state it was in for the selected import (the import you are rolling back to). It will have the OPS version ID of that import. | |
| Sign-Up | The data is extended to the end of the sign-up period as previously extended. This is identical to not having performed the rolled back import, but having extended the sign-up period. |