换用 Onplana 的那一天会有什么不同
手工重建
- 在新工具中逐个任务重画前置任务网络。
- 在旧文件中一个一个地查找每个链接的类型和延隔时间。
- 因为导入丢失了成本，只好重新输入。
- 日期开始变得不合理时，再去找你引入的那个循环。
直接导入
- 上传文件，网络随之而来。
- 每个链接都保留原有的类型和延隔时间。
- 成本，包括基线成本，在同一步中导入。
- 在你画出循环的那一刻，系统会在整个依赖关系图上将其拒绝。
工作原理
步骤 1
导入你已有的文件
直接上传 Microsoft Project 的 .mpp、MSPDI XML、.mpx 或 Primavera 的 .xer。任务、依赖关系、资源和成本一步导入；导入到新项目时，.mpp 或 Project XML 文件中的基线会成为一条基线，因此偏差报表从第一天起就能使用。当文件的工作日历与组织的默认日历不同时，新项目也会采用文件的工作日历，因此日期会按文件排定进度时所用的工作周重新计算。
步骤 2
每个链接都带着它的类型和延隔时间
完成-开始、开始-开始、完成-完成和开始-完成，每一种都保留源文件中的延隔时间。同一对任务可以有多个链接，因此同一对任务之间的 SS 和 FF 都会被保留。
步骤 3
日期变动时，关键路径依然实时
拖动一个条形，后续任务随之移动。关键路径按项目日历重新计算，而不是手工重画；会造成循环的链接在你画出时就会被拒绝。
证据
进度引擎对 Microsoft Project 的全部 8 种限制类型建模，而不只是 4 种，自 2026年9月 起即是如此。延隔时间精确保存到分钟，导入时不会取整到天。
8 是 Microsoft 的数字，不是我们的： 它的“限制类型”字段参考 （英文） 列出了这些类型。其余的也不必只听我们说： Schedule Health Check 会读取你的文件，并在你创建任何内容之前报告它发现的情况。
费用，以及它不做什么
依赖关系、带关键路径的甘特图和项目文件导入，全部包含在 Free 方案中，没有最低席位要求。它取代了你只为让某人能继续打开进度计划而保留的那份桌面许可证。
坦白说明的局限
进度计算以整天为单位。不足一天的延隔时间会被精确保存、精确显示、精确重新导出，但后续任务会按取整到最接近的整个工作日后的延隔时间移动，而 Microsoft Project 会按实际小时数移动它。如果你的计划依赖不足一天的延隔时间才能正确，这个差异与你有关，你应该在换用 Onplana 之前了解它，而不是之后。
换用 Onplana 之前常被问到的问题
从 .mpp 导入后，4 种依赖类型都能保留吗？
能。完成-开始、开始-开始、完成-完成和开始-完成都会导入，每一种都带着它的延隔时间。限制类型也会导入，是 Microsoft Project 的全部 8 种，而不只是 4 种。
不是整数天的延隔时间会怎样？
它会按文件中的原样精确保存到分钟，重新导出时也不会改变。目前进度计算以整天为单位，因此不足一天的延隔时间会被如实保留，但在排定后续任务时会取整到最接近的整个工作日。你的数据中没有任何内容被悄悄取整。
依赖关系可以跨项目吗？
可以，而且后续任务会遵守它：它的日期会以另一个项目中的任务作为固定锚点来计算。这种约束有意设计为单向。移动前置任务会在后续任务下一次计算时重新排定它，而不是进入另一个项目去改写没人要求修改的日期。
什么能阻止有人创建循环依赖？
链接在你画出时就会被拒绝。检查会遍历整个依赖关系图，而不只是紧邻的任务，因此从 A 到 B 到 C 再回到 A 的循环会在保存前被发现。
它包含在哪个方案中？
Free。依赖关系、带关键路径的甘特图和项目文件导入全都在其中，没有最低席位要求。进度计划的严谨性不是我们放在更高方案后面的东西。
我需要重建进度计划才能知道导入是否正确吗？
不需要。先把文件交给免费的 Schedule Health Check，它会在你创建任何内容之前报告它发现的情况，包括依赖关系的数量和它无法解析的链接。