Overview
"When you reset the begin and end dates of a project using this web service, the start and end dates of the roles, as well as the allocation dates, are also adjusted accordingly. For instance, if you delay the project end date by 5 days, the following changes will occur:
...
PwsAdvanceDelayProject can be used to shift a specified project in time. Advancing the project (by specifying a NewProjectOpenDate prior to the existing begin date) causes all dates to be shifted earlier (project is starting ahead of schedule); delaying the project (by specifying a NewProjectOpenDate after the existing begin date) causes all dates to be shifted later (project is starting behind schedule).
Some dates are shifted on a daily granularity, others on a weekly granularity, and yet others are shifted at varying granularities.
- For daily granularity, dates are simply shifted by the number of days difference between the original and new project begin dates.
- For weekly granularity, the number of weeks shifted is determined by calculating the number of weeks difference between the start of the week containing the original begin date and the start of the week containing the new begin date.
- For half-month, month, quarter and year granularities (time and cost budgets, cost plans), the number of time units shifted is calculated in a similar manner (for example, the number of quarters between the quarter containing the original begin date and the quarter containing the new begin date).
When a project is advanced or delayed:
- The project begin date is shifted to the newly specified begin date
- The project end date is shifted as follows:
- If NewProjectCloseDateClearFlag is set to true, it is cleared.
- If NewProjectCloseDate is not specified, and the existing end date is not set, it is left as is.
- If NewProjectCloseDate is not specified, and the existing end date is set, the existing end date is shifted at a weekly granularity relative to the project begin date (for example, if the new project begin date is shifted 2 weeks after the original begin date, the original end date is shifted by the same two weeks.
- If any of the above results in a project end date prior to any role end date or scheduling activity on the project, the end date is automatically stretched so as to not have role end dates or activity outside the project dates.
- Project rate begin and end dates are shifted on a weekly granularity.
- Project role start and end dates are shifted on a weekly granularity.
- Project role rate exceptions and RDC exceptions are shifted on a weekly granularity.
- Allocations are shifted on a weekly granularity.
- Time and cost budgets are shifted on a granularity depending upon the time phasing of the individual baselines (non-time phases budgets are not shifted at all).
- Cost plans are shifted on a granularity depending upon the time phasing of the individual baselines (non-time phases budgets are not shifted at all).
- Task plan earliest start dates and task baseline role start and end dates are shifted on a daily granularity.
Request Format
| Panel | ||
|---|---|---|
| ||
|
...
Element | Data Type | Required? | Default | Description | Sample Data |
|---|---|---|---|---|---|
Int32 | No | Click here for more information. | 1 | ||
String | Yes | Click here for more information. | AWXKNmZlvR5xkqVh6PAXqQ== | ||
LocksToSteal | No | This structure represents the locked state of a Projector entity such as an engagement or a project | |||
NewProjectCloseDate | DateTime | No | The new end date for the project, if any. | 2023-12-31z | |
NewProjectCloseDateClearFlag | Boolean | No | If set to 'true', the project end date, if currently set, will be cleared. | true | |
NewProjectOpenDate | DateTime | Yes | The new begin date for the project. | 2023-01-01z | |
ProjectIdentity | Yes | This structure identifies the project to be advanced or delayed. | |||
ProjectTimestamp | String | No | *** This field has been deprecated *** | ||
ProjectorLockSetId | Int32 | A projector lock set id is an identifier for a group of one or more locks held as a unit. | |||
AllowProjectDatesToStretchFlag | Boolean | No | false | When either the new begin or end date would be in conflict with role start and end dates or allocation dates after the operation is completed, the project dates begin date will be adjusted to resolve the conflict if this boolean value is set to 'true'. Otherwise, error 55037 will be thrown. For instance, suppose a role’s end begin date after the operation is completed is DecNov. 1230, 2022, and the project end begin date is currently set to NovDec. 3012, 2022. If the boolean value is set to ‘true’, Projector will change the project end begin date to DecNov. 1230, 2022, to resolve the conflict. However, if the boolean value is set to ‘false’, error 55037 will be thrown. Note that the project end date is automatically stretched as necessary, regardless of this setting. |
Request Usage Example(s)
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pws="http://projectorpsa.com/PwsProjectorServices/" xmlns:req="http://projectorpsa.com/DataContracts/Requests/" xmlns:sch="http://projectorpsa.com/DataContracts/Shared/Scheduling/" xmlns:com="http://projectorpsa.com/DataContracts/Shared/Common/">
<soapenv:Header/>
<soapenv:Body>
<pws:PwsAdvanceDelayProject>
<!--Optional:-->
<pws:serviceRequest>
<req:SessionTicket>AWXKNmZlvR5xkqVh6PAXqQ==</req:SessionTicket>
<sch:NewProjectCloseDate>2023-12-31z</sch:NewProjectCloseDate>
<!--Optional:-->
<!--sch:NewProjectCloseDateClearFlag>?</sch:NewProjectCloseDateClearFlag-->
<sch:NewProjectOpenDate>2022-01-01z</sch:NewProjectOpenDate>
<sch:ProjectIdentity>
<!--Optional:-->
<com:ProjectCode>LUCIA-001</com:ProjectCode>
</sch:ProjectIdentity>
<sch:AllowProjectDatesToStretchFlag>true</sch:AllowProjectDatesToStretchFlag>
</pws:serviceRequest>
</pws:PwsAdvanceDelayProject>
</soapenv:Body>
</soapenv:Envelope> |
...