| Table of Contents |
|---|
...
| Identifier | Data encoding rule | Remark |
|---|---|---|
| ER-01 | Each use of "daily", "on date", "date range", "on weekday", or "from weekday...to weekday" shall be encoded as a single Timesheet, according to the mapping table. | The rule could be deleted from here. A new rule chould be put under the common coding part: Each use of "daily", "on date", "date range", "on weekday", or "from weekday...to weekday" shall be encoded as a single Timesheet, according to the [TS] and [/TS] indications in the graphical elements mapping tables. Note: There exists already an indication in the common coding patterns, that separate Timesheets are needed but they are mentioned with respect to the diagrams. Probably needs to be deleted. |
| ER-02 | All Timesheets shall get timeReference=UTC and daylightSavingAdjust=NO. | |
| ER-03 | If "on date" is used, then both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for "on date". | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date, both the Timesheet.startDate and the Timesheet.endDate shall get the value specified for that date. |
| ER-04 | If "on date" or "date range" are used, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date or date range, then Timesheet.day shall get the value "ANY" and Timesheet.dayTill shall be left empty. |
| ER-05 | If "daily", "on weekday" or "from weekday...to weekday" are used, then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to one single date, a weekday or time interval spreading over multiple weekdays then in the corresponding Timesheet(s) both startDate and endDate shall be left empty. |
| ER-06 | If "on weekday" is used, then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty. | The rule could be deleted from here. A new rule chould be put under the common coding part: If the Timesheet is related to a weekday then Timesheet.day shall get that value and Timesheet.dayTill shall be left empty. |
| ER-07 | If "exc. date" is used, then it shall be encoded as one Timesheet that has excluded=YES, startTime=00:00 and endTime=24:00; startDate and endDate shall both get the value specified for "exc. date". | The rule could be deleted from here. A new rule chould be put under the common coding part: If excluded date is used, then it shall be encoded as one Timesheet that has excluded=YES, startTime=00:00 and endTime=24:00; startDate and endDate shall both get the value specified for the excluded date. Note: There exists already an indication in the common coding patterns regarding usage of excluded date. It probably needs to be updated but |
| ER-08 | The values WORK_DAY, BEF_WORK_DAY, AFT_WORK_DAY, HOL, BEF_HOL, AFT_HOL and BUSY_FRI cannot be used in Timesheet.day or Timesheet.dayTill. | |
| ER-09 | According to the OPADD, item D is not allowed to exceed 200 characters. The application interface should check the length of the item D that results from the schedule encoding and invite the operator to split the NOTAM into two separate events in case this limit is exceeded. The HMI should allow copying a draft event into a second draft event. | |
| ER-10 | It is not allowed to use "overnight" time periods in Event Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600. | The rule could be deleted from here. A new rule chould be put under the common coding part: It is not allowed to use "overnight" time periods in Schedules, e.g. 2200-0600. These shall be split into two separate time periods, e.g. 2200-2400 and 0000-0600. |
| ER-11 | If a schedule is more complex than the ones supported by the Templates provided for this scenario, then it shall be described in as a free text "note". | The rule could be deleted from here. A new rule chould be put under the common coding part: If a schedule is more complex than the types provided, then it shall be described in as a free text "note". |
...