关于计划节点延期的逻辑说明.docxVIP

关于计划节点延期的节点变更逻辑及思维 原需求方案： 保持各节点中逻辑关系，导入系统时仅识别各节点有逻辑关系存在，如B、C的前置任务为A：D的前置任务为B；E的前置任务为C。 识别这些关系后，如果B发生变更，弹出与B有直接逻辑关系的节点A、D（存在间接逻辑关系节点不弹出变更），让项目计划管理员自行改变A、B、D节点工期。同时还是保持识别各节点中存在逻辑关系。(即不通过时间关联识别紧前紧后，通过FS、SS、FF、SF、等逻辑关系识别紧前紧后逻辑即可） 原则还是节点的变更，只对有直接逻辑关系传递的节点进行变更，不对逻辑关系再次传递的节点进行变更。 这个设计的原意思为，计划导入的时候并不需要仔细识别每个节点之间的时间联系。只需要在“前置任务”一栏中，识别：“节点2”前置任务为“节点1”，后置任务为“节点3、节点4”。变更节点2时，同时拉出“节点1、3、4”让项目人员自行变更时间即可。 经过软件公司反映上述逻辑软件公司技术上无法实现后的后备方案（上述方案确实无法实现的备选）： 计划节点延期指的是在对节点“A”进度报告时，对节点“A”进行的延期处理。进行节点延期处理时有以下3个逻辑需要注意： 节点A进行变更时，可以和节点A一起调整“计划时间”的只有与节点A有直接逻辑关系的紧前紧后工序。 节点A的紧前紧后工序的下一级紧后工序，不予许变更“计划完成时间”。 对于已经确认完成的节点，不能进行变更。 只对紧后节点进行变更。 举例描述： 节点A的紧前工序为节点B、紧后工序为节点C、节点D；节点C的紧后工序为节点E、节点F；节点D的紧后工序为节点G。 节点A：计划开始时间为2017年3月2日，计划结束时间为2017年3月10日。 节点B：计划开始时间为2017年2月1日，计划结束时间为2017年3月1日。 节点C：计划开始时间为2017年3月11日，计划结束时间为2017年4月1日。 节点D：计划开始时间为2017年3月11日，计划结束时间为2017年5月3日。 节点E：计划开始时间为2017年4月2日，计划结束时间为2017年4月30日。 节点F：计划开始时间为2017年4月2日，计划结束时间为2017年6月7日。 节点G：计划开始时间为2017年5月4日，计划结束时间为2017年8月1日。 计划管理员对节点A发起变更： 由于节点B作为紧前工序，计划完成时间不会发生改变，节点A的计划开始时间则不发生改变，可变更节点A的完成时间：如变更为2017年4月10日。 节点C、节点D的开始时间则变更为：2017年4月11日。 节点C、节点D的完成时间可自由变更但不能超过紧后节点的完成时间：如节点C完成时间变更为2017年4月19日、节点D的完成时间变为2017年6月3日。（注意：系统需要设置节点C、节点D的变更完成时间不能超过其紧后节点的计划完成时间） 以下部分系统自动变更： 节点E的计划开始时间为保持逻辑关系连续，即需要变更为2017年2017年4月20日； 计划完成时间锁定不变，为2017年4月30日，保持与后续节点的逻辑关系联系。 节点F同理。