一个好的运输驾驶舱性能的关键是一个好的选择。选择尽可能多但尽可能少的数据将基本上节省驾驶舱中每次点击的响应时间。

无论从业务角度看是否合理，您都应该将场景分割。

如果您有非常特殊/例外的情况（例如通过添加货运单位来"修复"过去已经离开的货运订单）你应该考虑将你对一个场景的选择分成几个概要文件（例如，一个"完整"的例外文件，这是比较慢，但很少使用和一个较小的80%的情况下）。

我很肯定，你的企业也会理解使用两个配置文件为同一个场景，因为刨工的生活也将简化，如果他只看到他需要的80%的情况下。

规划配置文件

规划地平线定义了一个刨工的工作时间创建运输计划。从技术上讲，它控制几个与计划相关的功能，云指，例如：

–它定义了调度员可以安排订单的最外层角落

–它定义了优化器可以创建/交换/删除订单的角落

–它定义了哪些（从而间接地定义了多少）计划出发装载到运输驾驶舱

原因我告诉你这是说，至少手动规划与"过时"的规划视野仍然是可能的，但有限制。例如，如果您需要通过添加货运单位来修复旧的货运订单，但不关心正确的文档日期（因为订单是以任何方式执行的），您可以优化正常情况下的计划范围，并在不进行计划的情况下计划那些特殊情况。请注意，在计划会话期间，也可以使用"更改计划设置"按钮来增加计划期限。尤其是使用优化器，在过去开始规划地平线对我来说没有多大意义。我猜你永远不会希望在过去创建一个新的订单，仅仅是因为它本来很适合昨天推动货物的生产。

但是为什么一个大的计划范围会对某些行动的绩效产生如此糟糕的影响？原因主要是一些操作的上下文信息。假设优化器希望在单个资源上创建新订单。为了不产生重叠，我们需要读取计划期内的所有货运订单。

请注意，这种上下文确定对于正确的结果是绝对必要的，不能停用（与您在计划概要文件上激活的上下文确定无关）。

因此，总是尽量缩短你的计划时间。当然，我不能给出建议，多久可能适合，但你应该问你的业务。

他们通常计划在第二天？那么今天（执行计划）和明天就可以了？然后可以使用7天的偏移量和7天的地平线。对于特殊情况，您可以在接下来的14天内创建另一个配置文件。

选择配置文件

这里的规则与计划范围相同。请尝试选择与您的计划范围相对应的数据。如果你只是计划接下来的两周，那么在接下来的6个月里选择所有即将到来的需求是没有意义的。有时，在选择期的某个方向上增加或减少几天时间是有意义的，但你应该一如既往地以最小的期限来满足你的业务需求。

从绩效的角度来看，在与时间相关的选择配置文件中有一个非常危险的下拉框："使用索引时间进行选择"。

但这意味着什么，为什么它如此危险？在TM中，文档选择通常在stop级别工作，网络云服务器，这意味着我们根据某些stop属性选择文档。其中之一就是停车的时间。但是TM停止不是在某个时间点发生的，而是覆盖了几个时间段。但是在一个站点上有很多时间：开始/结束加载、开始/结束耦合、截止日期、要求/可接受的提货/交货时间等等。

如果您现在在某个日期搜索某些文档，系统需要检查数据库上的所有站点是否符合其中一个时间。

这需要很多时间。因此，我们发明了索引时间。它是一个定义停止的时间戳，用于选择（以及一些其他决策，例如，在调度多个订单时对一个资源的顺序）。

这个时间始终是文档在某种状态下最重要的时间。对于计划货运单位，总是计划出发/到达时间。如果货运单位仍然是计划外的，这是要求的日期，如果这一个没有填写可接受的日期。标准如何定义这个最重要的日期的逻辑在class/SCMTMS/CL\TOR\u D\u STOP\AM方法FILL\u SELECTION\u TIME\u PER\u STOP中定义。如果你不同意我们定义最重要日期的标准逻辑，你可以在这里添加一个post-enhancement.

我个人建议不要使用"使用所有停止时间"值！

今天我不想搞政治，但从选择的角度来看，最好是包含而不是排除。因此，在附加的选择属性中，如果可能的话，懒懒淘客，尝试用include语句而不是exclude语句来表示您的选择。例如，如果你想排除危险品，你应该用"危险品指标EQ false"来表示，而不是"危险品指标NE true"。当然，有时很难或不可能用白名单来表示选择。